git subtree issue in more recent versions

Hi,

I've discovered a bug in git subtree related to annotated tags. The command 'git subtree' will fail if you use an annotated tag as the <refspec>. e.g.:

$ git subtree add -P oldGit https://github.com/git/git.git tags/v1.9.2

Will produce this error:

10ff115f5c572299de4e04ade0d7adb3c75fbf1f is not a valid 'commit' object

The bug isn't found in 1.7.1 (installed subtree manually) but is found in 1.9.0 and 2.0.0.rc1. 

It's related to the git fetch putting the "wrong" SHA1 in .git/FETCH_HEAD. Thus, if you do:

$ git ls-remote https://github.com/git/git.git | grep v1.9.2

You'll see this: 10ff115f5c572299de4e04ade0d7adb3c75fbf1f refs/tags/v1.9.2 0bc85abb7aa9b24b093253018801a0fb43d01122 refs/tags/v1.9.2^{}

An older version will put the 0bc85a in FETCH_HEAD but newer versions will put 10ff11 which will not work. I'm new to Git so I don't know when/why that was changed but somewhere along the way, that change broke git subtree add. :( A workaround is to use lightweight tags but that's not suitable for some. 

Thanks, Kevin

"Kevin Cagle (kcagle) [CONT - Type 2]" <kcagle@micron.com> writes:

The change 7a2b128d is very much deliberate; we wanted not to lose information that the user was trying to pull a tag not a commit, because not unwrapping a tag to a commit it points at too early is essential to allow pulling and merging a signed tag, which was released as part of the 1.7.9 that happened in late January 2012 (whew, is it already more than two years ago? time flies).

    commit 7a2b128d13d880635e7317a9208cfa42a660f143
    Author: Linus Torvalds <torvalds@linux-foundation.org>
    Date:   Wed Nov 2 19:19:34 2011 -0700

    fetch: do not store peeled tag object names in FETCH_HEAD
    
    We do not want to record tags as parents of a merge when the user does
    "git pull $there tag v1.0" to merge tagged commit, but that is not a good
    enough excuse to peel the tag down to commit when storing in FETCH_HEAD.
    The caller of underlying "git fetch $there tag v1.0" may have other uses
    of information contained in v1.0 tag in mind.

If the caller of "fetch" (like the codepath in subtree) must see a commit object, it needs to unwrap the tag itself in the new (eh, not so new, though ;-) world order.