Linus Torvalds [off-list ref] writes:

If you do a

  git pull linus v3.4-rc5

in order to just update to the state of my latest tag, then git will
assume you want to do a new commit (and thus a non-fast-forward) just
so that git can record the tag signature in the commit.

The sad part is that I don't think you can even override the second
case.
...
That's inconvenient, and an unintended consequence of the behavior I
wanted as a top-level maintainer. But I really do think it's wrong for
normal developers who might validly just want to update to some
particular tagged release.

Junio? Any ideas?

"Ideas" meaning "recipe to do with deployed binaries"?

When a normal developer wants to _reset to_ a particular tagged release,
in order to _start_ new work, she wouldn't be doing even the above "git
pull linus v3.4-rc5".  That will contaminate the result with whatever
random stuff she happened to have on the current branch.  A more natural
sequence would be "git fetch --tags linus" followed by either

        git checkout v3.4-rc5 ;# to detach

or

        git checkout -b mywork v3.4-rc5 ;# to start

So the case to "reset to" is not very interesting.

But when a normal developer wants to _sync to_ a particular tagged
release, in order to _continue_ working on her topic, she would need to
have a merge (unless she does not have _anything_ herself), and at that
point, merging v3.4-rc5 vs v3.4-rc5^0 would not make that much of a
difference.  If she absolutely detests the "mergetag" header, she could do
a "git fetch --tags linus" followed by

	git merge v3.4-rc5^0

which admittedly is two more letters than she used to type.

If you mean by "Ideas" for additional features, obviously the last step
could be enhanced to use a more intuitive command line that requires the
user to type even more, i.e.

	git merge --ff v3.4-rc5

Once that is done, "git pull --ff linus v3.4-rc5" would fall out as a
logical consequence.

But obviously these two would need new code ;-)