Re: Preserving branches after merging on ancestor

On 2009.11.05 16:30:04 -0600, Jonathan Nieder wrote:

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.

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. And your example _still_ has such a fast-forward.

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]

And here you got a fast-forward of master to feature2, i.e. linear
history, which is what Richard was trying to avoid.

Instead of:

A---B---C---D---E (topic2) (master)
     \
      F---G---H (topic1)

He wants:

      F---G---H (topic1)
     /
A---B-----------M (master)
     \         /
      C---D---E (topic2)

So he can see at which point topic2 got merged. This allows to ask "which
commits got merged here" (and for a merge-once topic branch this means:
Which commits are related to that topic), by using for example:

git log M^1..M^2 # Will show C, D and E

In the fast-forward case, there's no way to get that without manually
figuring out where the topic branch started.

Björn