Re: Preserving branches after merging on ancestor

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2009.11.06 07:21:17 -0800, rhlee wrote:
> 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.

> 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