Re: git merge and merge message

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mar 11, 2007, 20:19 UTC
Message-ID: <Pine.LNX.4.64.0703111309410.9690@woody.linux-foundation.org>
In-Reply-To: <200703111815.l2BIFHbq010315@localhost.localdomain>

On Sun, 11 Mar 2007, Xavier Maillard wrote:

Show 12 quoted lines

>    On Sun, Mar 11, 2007 at 04:05:04PM +0100, Xavier Maillard wrote:
>    > The merge is correct but there is not merge message when I do a
>    > git log.
> 
>    Have you done any work on the master branch since you branched the topic
>    branch off from it?  If not, the merge is just a "fast forward"--no
>    merge commit is created, and instead the head of the master branch is
>    just updated to point at the same commit as the head of the topic
>    branch.
> 
> No I did not touch master before. It could explain that behaviour
> then :)

Indeed.

The "don't merge, just fast-forward" is the right thing to do for working together. However, I can well imagine that if you actually work with branches not as "distributed development", but *just* as "topic branches", then having the "useless" merge (with the parents actually being parents of each other) migth actually be nice from a documentation standpoint.

I'm torn on this. I really dislike anything but fast-forward, because I have a strong suspicion that it will cause "alpha male" behaviour (where maintainers use the "useless merge" as a way to mark their territory), which I think is actually really bad form.

At the same time, I think that the kind of behaviour that Xavier is talking about, where you actually end up having feature branches for your own project, and then using

	git merge -m "Merge feature Xyz" xyz-branch

is potentially a really good way of making it clear that the code along the branch you merged did Xyz.

My other rule in life is that a tool should not *force* a certain policy (although encouraging good behaviour by making that the *easy* thing to do is a good idea), so I think that it would probably be ok to add a flag to "git merge" to say "force a merge commit", which would disable the fast-forward behaviour.

(And if you don't support it for "git pull", maybe that's enough of a disincentive that you won't see the "maintainer marking his territory by peeing in the snow" behaviour).

Comments? Do people think it would be a good idea to do

	git merge --no-fast-forward -m "Merge feature Xyz" xyz-branch

as an option?

			Linus