Re: git subtree issue in more recent versions

"Kevin Cagle (kcagle) [CONT - Type 2]" [off-list ref] writes:

$ 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.

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 [off-list ref]
    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.