[PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag

[PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag

[James Denholm]

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(-)

diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index dc59a91..eefd720 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -557,8 +557,9 @@ cmd_add_commit()
 		commit=$(add_squashed_msg "$rev" "$dir" |
 			 git commit-tree $tree $headp -p "$rev") || exit $?
 	else
+		revp=$(peel_committish "$rev")
 		commit=$(add_msg "$dir" "$headrev" "$rev" |
-			 git commit-tree $tree $headp -p "$rev") || exit $?
+			 git commit-tree $tree $headp -p "$revp") || exit $?
 	fi
 	git reset "$commit" || exit $?
 	
-- 
1.9.2

Re: [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag

[Junio C Hamano]

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

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

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(-)

diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index db925ca..fa1a583 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -558,8 +558,9 @@ cmd_add_commit()
 		commit=$(add_squashed_msg "$rev" "$dir" |
 			 git commit-tree $tree $headp -p "$rev") || exit $?
 	else
+		revp=$(peel_committish "$rev") &&
 		commit=$(add_msg "$dir" "$headrev" "$rev" |
-			 git commit-tree $tree $headp -p "$rev") || exit $?
+			 git commit-tree $tree $headp -p "$revp") || exit $?
 	fi
 	git reset "$commit" || exit $?
 	
-- 
2.0.0-rc3-404-gb0be553

Re: [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag

[James Denholm]

On Tue, May 13, 2014 at 12:34:13PM -0700, Junio C Hamano wrote:
> James Denholm <nod.helm@gmail.com> writes:
> > I felt that defining revp would be a little more self-documenting than
> > using $rev^0.
> 
> 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'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.

> I'll tentatively queue this.  Thanks.

Awesome, thanks again for this and the feedback.

---
Regards,
James Denholm.

Re: [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag

[Junio C Hamano]

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

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

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

Re: [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag

[James Denholm]

On Tue, May 13, 2014 at 04:12:56PM -0700, Junio C Hamano wrote:
> James Denholm <nod.helm@gmail.com> writes:
> 
> > 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.
> 
>  $ git fetch git://repo.or.cz/alt-git junio-gpg-pub
>  $ git rev-parse FETCH_HEAD^0

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.

Re: [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag

[Junio C Hamano]

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

> On Tue, May 13, 2014 at 04:12:56PM -0700, Junio C Hamano wrote:
>> James Denholm <nod.helm@gmail.com> writes:
>> 
>> > 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.
>> 
>>  $ git fetch git://repo.or.cz/alt-git junio-gpg-pub
>>  $ git rev-parse FETCH_HEAD^0
>
> 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?

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.

Re: [PATCH v2] contrib/subtree bugfix: Can't `add` annotated tag

[James Denholm]

Junio C Hamano wrote:
> 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.

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

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

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.