v2contrib/subtree bugfix: Can't `add` annotated tag

cmd_add_commit() is passed FETCH_HEAD by cmd_add_repository, which is then rev-parsed into an object ID. However, if the user is fetching a tag rather than a branch HEAD, such as by executing:

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

The object ID is a tag and is never peeled, and the git commit-tree call (line 561) slaps us in the face because it doesn't handle tag IDs.

Because peeling a committish ID doesn't do anything if it's already a commit, fix by peeling[1] the object ID before assigning it to $rev, as per the patch.

[*1*]: Via peel_committish(), from git:git-sh-setup.sh, pre-existing dependency of git-subtree.

Reported-by: Kevin Cagle <kcagle@micron.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: James Denholm <nod.helm@gmail.com>
---
I felt that defining revp would be a little more self-documenting than
using $rev^0.

 contrib/subtree/git-subtree.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

James Denholm <nod.helm@gmail.com> writes:

That is a good decision, but as long as we are attempting to peel, don't we want to stop the damage when it does not peel to a commit?

I'll tentatively queue this.  Thanks.

-- >8 --
From: James Denholm <nod.helm@gmail.com>
Date: Tue, 13 May 2014 14:08:58 +1000
Subject: [PATCH] contrib/subtree: allow adding an annotated tag

cmd_add_commit() is passed FETCH_HEAD by cmd_add_repository, which is then rev-parsed into an object name. However, if the user is fetching a tag rather than a branch HEAD, such as by executing:

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

the object name refers to a tag and is never peeled, and the git commit-tree call (line 561) slaps us in the face because it doesn't peel tags to commits.

Because peeling a committish doesn't do anything if it's already a commit, fix by peeling the object name before assigning it to $rev, using peel_committish() from git:git-sh-setup.sh, a pre-existing dependency of git-subtree.

Reported-by: Kevin Cagle <kcagle@micron.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: James Denholm <nod.helm@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 contrib/subtree/git-subtree.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

On Tue, May 13, 2014 at 12:34:13PM -0700, Junio C Hamano wrote:

I'm not sure that can actually happen - peel_committish is essentially implemented as `rev-parse $arg^0` (though with a bit of bling, of course), and to my understanding FETCH_HEAD will always parse to a committish - I could have missed something, of course.

subtree Will need error-catching at some point, of course, triggering resets or at least suggesting instructions to the user, but I think that's a touch out of the scope of a bugfix at this point (and, to be honest, I personally can't allocate the time to that for about a month due to the dark shadow of academic exams). Indeed, what to do in those cases is probably worth (re-)discussing the overall design and aims of subtree for, and so I'm not confident that I currently know the best way to do that.

Awesome, thanks again for this and the feedback.

--- Regards, James Denholm.

James Denholm <nod.helm@gmail.com> writes:

 $ git fetch git://repo.or.cz/alt-git junio-gpg-pub
 $ git rev-parse FETCH_HEAD^0

On Tue, May 13, 2014 at 04:12:56PM -0700, Junio C Hamano wrote:

That would be a problem... Sadly I doubt I'll have time to develop a solution into subtree's overall design before the end of June. As that eventual change would probably involve altering the inclusions of this fix, and that users have a workaround in adding either squashed commits or referencing lightweight tags, would you rather drop the patch and wait for that?

--- Regards, James Denholm.

James Denholm <nod.helm@gmail.com> writes:

Sorry, I am lost.  What would be a problem exactly?

A FETCH_HEAD can be pointing at an object that is not committish, and users involved, both at the originating end who controls the repository you fetched from and at the receiving end who wanted to fetch the object, are *not* expeting to be able to make a merge of such an object anyway. My suggestion was not to ask you to come up with a sane behaviour when the user told us to add a single blob with "subtree add"; it was merely to detect such unintended use as an error.

To me, it looks like all that is necessary is to accept your patch but with a three-byte tightening to detect such a pathological case and signal an error, which is what " &&", which I added to your new line that sets revp=$(peel_committish ...), is about.

This patch, with or without these extra " &&" three bytes, will not be part of the upcoming 2.0 release anyway, so we have enough time to iron it out.

Junio C Hamano wrote:

Ah, right, sorry, somehow I missed the " &&" in the amended patch. I don't know how I overlooked that. That indeed would be plenty.

Yeah, what I meant by problem was the possibility of finding a way to pre-empt the case of a tag pointing to a blob and handle it as gracefully as possible, and try to leave the user with their working tree in the state from before the subtree call.

The reason I'd suggest it might be worth handling at some point is that (in the far flung future) it may not be out of the scope of subtree to pull not only other repos to a local subtree, but also specific trees (or perhaps blobs) to a local subtree. Conceptually, I'd argue that a sensible future functionality in order to allow subtree users to deal with upstreams that don't split their projects up sanely (cough splutter Facebook's internal). Hence, working out a way to determine tag types, possibly before doing the fetch somehow, would be a boon to that methinks.

Of course, this is something I haven't yet thought enough about and the idea is likely full of holes, but hey, I'm nothing if not impractically idealist.

--- Regards, James Denholm.