Re: git merge and merge message

Linus Torvalds [off-list ref] writes:

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.