Re: Preserving branches after merging on ancestor

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Nov 6, 2009, 22:52 UTC
Message-ID: <20091106225250.GA14642@progeny.tock>
In-Reply-To: <1257520877359-3959325.post@n2.nabble.com>

Richard Lee wrote:

> Jonathan Nieder wrote:

Show 8 quoted lines

>> 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?

Well, no. Some of us (read: I) just haven’t figured out yet how to fit the --no-ff option into a broader workflow yet. It is only two years old. :)

There are pros and cons to using --no-ff to merge topic branches.  Pros:

 * 'git log --first-parent' will give the list of topics now.
 * The beginning and end of each topic is not forgotten by a clone any
   more.

Cons:

 * The perceived beginning and end of a topic might be irrelevant or
   misleading.
 * Every topic needs a good name. :)
 * More commits for a person looking through the history to deal with.
   A merge commit from a would-be fast-forward records content identical
   to its second parent, and it is not necessary as glue to tie the
   content-changing commits together any more.

After thinking about it a little, the pros seem to far outweight the cons.

Show 13 quoted lines

>> Björn Steinbrink 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"?

Yes, in my opinion. I prefer to branch topic1, branch topic2, ... and only later (after some time to reflect) decide which topics to merge. For this to work, each topic should not have all previous topics as ancestors, or there is no way to postpone merging any one.

This is especially nice when a topic turns into a long-term project. By not merging in the partial work, I keep the code in the master branch a little cleaner, but more importantly, bugs in the partial work do not interfere with work on other topics. Once it is finally time to merge the topic back to master, it is in one clean merge, and all the commits are together for someone looking at the history.

“What about testing?” one might ask. “How can I tell when it is safe to merge the topic to master, when the topic and other features since then might work well separately but not together?” The “Throw-away integration” section in gitworkflows(7) [1] discusses how to deal with this.

Taking the idea of forking from the oldest relevant commit to an extreme in a single-person project, you can end up with history like this:

initial---------------final
       \             /|
        \---A-------/ |
         \         / /|
          \---B---/ / |
           \       /  |
            \---C--   |
             \       /
              \--D---
               \
                -E- ...

i.e., full of octopus merges and basically unreadable in gitk. Arguably, this is at least partially a gitk bug. [Aside: a dream feature for gitk would be to give the --first-parent history at first and then fill in topics when the user requests them. That is, in this example, it would show

  initial---final

but after a click on the parent A, it would show

  initial---final
         \ /
          A

and so on.] To avoid this, it is best not defer merging topics into the mainline for too long, and to base each topic branch not on the oldest relevant commit but on the tip of the oldest branch it might be merged to (which in the simplest case is usually the mainline).

A single person has a lot of control over the shape of the history, so that it is easy to make it totally linear or sequence of enormous octopuses. The nicest history for others to read, I think, is that most like one created by many people in a healthy project. But that’s a hard ideal to achieve, and more important than crafting well shaped history is to write good code, so it is not worth obsessing over.

I hope that is a little clearer.

Regards, Jonathan

[1] http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_throw_away_integration