Looking at the pike-librarian for last friday, I see .gitignore being fixed for the whitespace problem in 8 branches. So I would have expected to see 8 commits. But instead I see a 8 commits, and 14 merges. This looks cluttered and bizarre to me. Why weren't the fixes simply done on one branch and then cherry-picked to the others, instead of this self-indulging juggling with merges?
It was an experiment in doing backporting the "git-way", where the patch is done to the most recent common ancestor to all the target branches, and then merged successively into the target banches.
Seems like a failed experiment to me, then. ;-)
If it had been a feature-branch with a descriptive name, then "merged X" would have been a reasonable description of the change. Right now it just looks crazy.
Please always rebase changes consisting of one (or just a few) commits.
I second that; rebasing and cherry picking is the way to go.
It's a pity that git still hasn't learned Origin headers when cherry picking, though. But this way of recording the patch relations is simply too clumsy imo.
At least this method didn't give false merge relations between the main branches. That is something I'd consider bad enough to actually warrant backing up branch heads on the server, since it'd bring in all commits from another branch when listing the history of one branch. It'd be nice if githelper could be extended to block such merges, i.e. if a commit moves the merge base between any two main (X.Y-style) branches, it's blocked.
It'd be nice if githelper could be extended to block such merges, i.e. if a commit moves the merge base between any two main (X.Y-style) branches, it's blocked.
Well, we'd have to add a definition of a "main branch" to the code then. Right now it's mostly generic. And if it should work with commit and not just push, it also needs to consider local branches tracking a "main branch" at origin.
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum