Re: git merge and merge message

From: Junio C Hamano <junkio@cox.net>
Date: Mar 11, 2007, 20:56 UTC
Message-ID: <7vwt1nv6r5.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0703111309410.9690@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 26 quoted lines

> 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

For one thing, this would make the earlier "first parent log summary" idea useful again.

The big picture of the evolution history of my 'next' can be seen by taking only the first parent ancestry, since the commit message in each of them has the summary of commit^..commit, coming from the fmt-merge-message output. This is because there won't be any fast-forward on 'next' as I never fork off of the tip of 'next'.

However, that is not true for my 'master'. When I merge a topic back into 'master' when the 'master' hasn't added any obvious and trivial fixups or improvements since the topic forked, it would result in a fast-forward. --no-fast-forward can be used to cure this.

So in that sense I think --no-fast-forward is a useful ingredient to make a history that is easy to read in "fast parent log" fashion, but:

  (1) it is only just one "enabler" -- you still need the
      discipline to build your history that way, and

  (2) it is dubious if it is really useful to present the
      history in "fast parent log" fashion for even trivial
      topics.

Regarding (2), a fast-forward into the trunk (or master) is a sign that nothing else was going on in the meantime, so it is either the series was very short (suggesting "_trivial_ changes on top of master"), and/or the only focus of the project during that timeperiod (suggesting "trivial changes _on top of master_"), either of which may mean that it would be good enough to just have a commit log message that says "This concludes the series I started at commit Xyz to do blah" without having an extra forced merge.

If the answer to (2) is "yes, it is useful", then maybe building such a history needs to be helped with more tool support (that is my point (1) above).

For example, _if_ I wanted to (mind you, in reality I don't think I necessarily do), I could forbid direct single-parent commits on top of 'master' branch, and force --no-fast-forward when merging to 'master' branch. That perhaps would be achieved by marking the branch with 'branch.master.integrationonly = true' configuration.