Re: [1.7.9] usage regression when merging annotated tag objects

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.