Some examples you gave were irrelevant, so I'd give an updated version.
Here are the facts of the day, without judging if the behaviour is good or
bad.
1) If you are at Linux v3.2.2 and do not have any development on top,
$ git merge v3.2.3
historically would have fast-forwarded. Git v1.7.9 would now create a
merge commit, authored by you (who is unlikely to be Linus).
2) You do not want such a merge, so try to work it around by this:
$ git merge --ff-only v3.2.3
fatal: Not possible to fast-forward, aborting.
which is refused because merging a tag object requires a new merge
commit.
Here are my assessments.
1. I do not think the first one is a real issue. 99% of the people who are
merely following along the upstream will never say "git merge v3.2.3".
They will instead say "git pull" and this _will_ fast-forward. No
merging of tag objects involved. Also when they want to check out that
specific version, they won't be using "git merge". It will be "git
checkout v3.2.3". So I do not think this is an issue for the case
where it used to result in a fast-forward.
1.5 A variant of the first one is when you have forked and are trying to
synchronize with the latest stable. In that case, you _do_ want a merge
to happen. It is possible that you may not want to get the "mergetag"
header in the resulting merge commit, and "git merge v3.2.3^0" is a new
way to do so.
Strictly speaking, this _is_ a usage regression caused by the new
meaning "git merge" gained in v1.7.9. Recording the tag in the a merge
commit, however, is the whole point of "git merge v3.2.3" that is given
a tag; this behaviour is not going to to change.
2. This is somewhat problematic. "git merge --ff-only v2.6.29" to people
who merely follow Linus has always been possible, and I would expect it
to be the case.
But again, the reason they said --ff-only in the first place is because
they feared that they might have some unexpected commits in their
history, and asked "git merge" to error out if the command has to
create a merge to let them know. So at that point, they could be
trained to run "git merge --ff-only v3.2.3^0" instead, *given enough
clue*.
The problem is that we are not giving enough clue. We just say "Not
possible to fast-forward" without explaining why.
We could solve this in one of two ways. We could tell them to merge
v3.2.3^0 instead. Or we could just go ahead and do that for them
automatically ourselves. I am inclined to say that we should unwrap
the tag given from the command line when --ff-only was given, i.e. we
do the latter.
--
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