Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html