Re: Preserving branches after merging on ancestor

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Nov 7, 2009, 13:28 UTC
Message-ID: <20091107132840.GA9303@atjola.homenet>
In-Reply-To: <1257520877359-3959325.post@n2.nabble.com>

On 2009.11.06 07:21:17 -0800, rhlee wrote:

Show 10 quoted lines

> Jonathan Nieder-2 wrote:
> > 
> > Then your response pushed me towards the question of whether --no-ff is a
> > good idea in general
> > 
> 
> John, I get the feeling from what you say in general that fast forwards are
> default behaviour for merges for a reason and by using the --no-ff option I
> am making my workflow and git history uncessesarily awkward and working
> against best practices?

As Jonathan already said, there are pros and cons when the merge is about merging topic branches to some "main" branch. In addition to that, working with git often also involves other merges. For example, you might have your private topic branch, on which you work on two different boxes. So you push your topic branch to some private bare repo, fetch it from the other box, work there, and push the result back to the bare repo. And then, in the "original" repo, you of course want to update your local branch head to reflect the new changes. So you fetch and merge, but you really don't want a merge commit in that case, but the default fast-forward behaviour. In some sense, that kind of "merge", is more like an "update", for which the fast-forward behaviour is simply better.

Show 13 quoted lines

> Jonathan Nieder-2 wrote:
> > 
> >> I guess Richard took the "branch topic1, merge topic1, branch topic2, 
> >> merge topic2" thing just as an example because that ends up with two 
> >> fast-forwards.
> > 
> > Hmm, I found Richard’s example pretty realistic.  I used to work like
> > that, and I don’t think I am the only one.
> > 
> 
> I'm not saying there is any one "right" workflow. But is there a more
> suitable workflow than than "branch topic1, merge topic1, branch topic2,
> merge topic2"?

That order of commands looks like a strict "Start a topic, finish a topic, merge it, start next topic, ..." workflow. And that severely limits what you can do, as you're forced to work on only one thing and to finish it first before starting something else. Such a strict workflow basically makes branching pointless. I often do things like:

git checkout -b new_feature master *work & commit*

*get a bug report about the stable version* git checkout -b bug_fix_foo maint *work & commit*

*get a report about a trivial bug on master* git checkout master *fix bug & commit* # Yes, directly on master git push

git checkout bug_fix_foo *finish the bug_fix* git checkout maint git merge bug_fix_foo # Merge the bugfix to the oldest branch it applies to git checkout master git merge maint # Merge bugfixes forward to the more recent branches git push

git checkout new_feature *finish feature* git checkout master git merge new_feature git push

So I could work on multiple things at the same time, and even merged them in reverse order, compared to the order in which I started the branches. It's just the strict "start, finish, merge, start next, ..." order that looks suspicious, but that's totally unrelated to the --no-ff thing. Even when working on multiple branches and merging them in a random order, you can hit a fast-forward for the "first" merge.

Björn