Re: Preserving branches after merging on ancestor

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Nov 5, 2009, 22:30 UTC
Message-ID: <20091105223004.GA3224@progeny.tock>
In-Reply-To: <26217077.post@talk.nabble.com>

Hi Richard,

Richard Lee wrote:

Show 21 quoted lines

> One way of getting round this problem is to use empty commits on the master
> branch, as shown below.
> 
> *   6fc04b5 Merge branch 'feature2'
> |\
> | * 07a117b stuff on feature2
> * | 52f5ba1 Empty commit
> |/
> *   5deaa93 Merge branch 'feature1'
> |\
> | * b163b17 stuff on feature1
> | * 53bb820 stuff on feature1
> | * c9ef14c stuff on feature1
> * | 34227a3 Empty commit
> |/
> * e88d332 Init
> 
> But is this correct? It seems rather hackish to create empty commits on the
> master branch just to historically preserve commits on a seperate branch.
> Should I be using feature branches in git like this or another way? For
> example more informative commit messages.

As Eric said, you can avoid the empty commits by passing 'git merge' the --no-ff option, which would give the history I think you intend:

*   26749ab Merge branch 'feature2'
|\
| * b9cd8ff stuff on feature2
|/
*   829ba2c Merge branch 'feature1'
|\
| * b163b17 stuff on feature1
| * 53bb820 stuff on feature1
| * c9ef14c stuff on feature1
|/
* e88d332 Init

But doing this misses some of the main benefits of feature branches imho.

If you base each feature branch on the stable release or features it depends on instead, this gives you the freedom to merge one feature without the others to another branch. For example:

# wouldn’t feature1 be neat? let me try it. git checkout -b feature1 v1.0 hack hack hack # looks good. git commit -a

# how about an unrelated feature2? git checkout -b feature2 v1.0 hack hack hack # looks good. git commit -a

# but do they work? git checkout v1.0; # detach head for testing [1] git merge feature1 feature2 make check # hmm, these don’t seem to work well together ... (investigating some more)

# looks like feature1 is not ready for prime time # so let’s just use feature2 for now. git checkout master git merge feature2 git branch -d feature2 make check # looks good; better publish it. git push origin master

v1.0 --- feature1
    \
     \-- feature2 [master]

As a nice side-effect, if you work this way then you can develop feature2 without being distracted by new bugs introduced by feature1.

With many features built this way, the revision graph starts to give some hints about relationships between features developed around the same time. For example, with the history

v1.0 --- feature1 --- feature2 -- feature4 -- feature6 - v1.1
                               \                        /
                                -- feature5 ------------

feature4 and feature5 are not likely to be closely related, but feature4 and feature6 might be. The exact history of merges is less important than the general "shape" of the graph.

Thanks for the food for thought.

Hope that helps, Jonathan

[1] See <http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html#_detached_head>.