Questions/investigations on git-subtree and tags

Questions/investigations on git-subtree and tags

[Jeremy Rosen]

Hello everybody


I am trying to use git-subtree to follow a subproject but I have a couple of problems and I am not sure if I am doing something wrong 

Basically I am trying to use a tag on the subproject as my "base" for the subproject but subtree doesn't seem to handle that properly


my first attempt was to simply do 

"git subtree add --squash git://git.buildroot.net/buildroot 2013.02" 

but subtree refused, telling me that the SHA of the tag is not a valid commit. 
Ok it makes sense, though I think this is a very valid use-case...

so I tried

"git subtree add git://git.buildroot.net/buildroot 2013.02^{commit}" 

which was refused because git fetch can't parse the ^{commit} marker.
Again it makes sense, but I really want to start from that tag.


so I tried

"git fetch git://git.buildroot.net/buildroot 2013.02"
"git subtree add --squash FETCH_HEAD"

which worked. Ok at that point I am slightly abusing git subtree, but it seems a valid usage

except that this last attempt causes serious problems when trying to split out the tree again

the call to "git commit-tree" within "git subtree split" complains that the SHA of the parent
is not a valid commit SHA. Which is true, it's the SHA of the tag.


At this point I am not sure if I am abusing subtree, if I have a legitimate but unimplemented use-case and how to 
fix/implement it.

the squash-commit message only contains the SHA of the tag, should it contain the SHA of the commit ?

"subtree split" can only handle commit SHA, should it somehow follow tag SHA too ? how ?

this is probably a trivial fix for someone with good knowledge of git-subtree but i'm not there yet, so any hint would be welcomed

    Regards

    Jérémy Rosen

fight key loggers : write some perl using vim

Re: Questions/investigations on git-subtree and tags

[Paul Campbell]

On Thu, Mar 7, 2013 at 10:25 AM, Jeremy Rosen <jeremy.rosen@openwide.fr> wrote:
> Hello everybody
>
>
> I am trying to use git-subtree to follow a subproject but I have a couple of problems and I am not sure if I am doing something wrong
>
> Basically I am trying to use a tag on the subproject as my "base" for the subproject but subtree doesn't seem to handle that properly
>
>
> my first attempt was to simply do
>
> "git subtree add --squash git://git.buildroot.net/buildroot 2013.02"
>
> but subtree refused, telling me that the SHA of the tag is not a valid commit.
> Ok it makes sense, though I think this is a very valid use-case...
>
> so I tried
>
> "git subtree add git://git.buildroot.net/buildroot 2013.02^{commit}"
>
> which was refused because git fetch can't parse the ^{commit} marker.
> Again it makes sense, but I really want to start from that tag.
>
>
> so I tried
>
> "git fetch git://git.buildroot.net/buildroot 2013.02"
> "git subtree add --squash FETCH_HEAD"
>
> which worked. Ok at that point I am slightly abusing git subtree, but it seems a valid usage
>
> except that this last attempt causes serious problems when trying to split out the tree again
>
> the call to "git commit-tree" within "git subtree split" complains that the SHA of the parent
> is not a valid commit SHA. Which is true, it's the SHA of the tag.
>
>
> At this point I am not sure if I am abusing subtree, if I have a legitimate but unimplemented use-case and how to
> fix/implement it.
>
> the squash-commit message only contains the SHA of the tag, should it contain the SHA of the commit ?
>
> "subtree split" can only handle commit SHA, should it somehow follow tag SHA too ? how ?
>
> this is probably a trivial fix for someone with good knowledge of git-subtree but i'm not there yet, so any hint would be welcomed
>
>     Regards
>
>     Jérémy Rosen
>

Hi Jérémy,

Git subtree ignores tags from the remote repo.

To follow a project in a subdirectory I would use git-subtree add
selecting a branch, not a tag, from the other repo. Then use
git-subtree pull to keep yourself updated.

e.g.

To add:

git subtree add --prefix=$subdir $repo $branch

Then to update:

git subtree pull --prefix=$subdir $repo $branch

If you make any changes on the branch and wanted to push them back you
could do that with:

git subtree pull --prefix=$subdir $repo2 $branch2

$repo2 and $branch2 would be different from $repo and $branch if you
wanted to push to your own fork before submitting a pull request.

-- 
Paul [W] Campbell

Re: Questions/investigations on git-subtree and tags

[Jeremy Rosen]

> 
> Hi Jérémy,
> 
> Git subtree ignores tags from the remote repo.
> 

is that a design decision or a case of "not implemented yet"

> To follow a project in a subdirectory I would use git-subtree add
> selecting a branch, not a tag, from the other repo. Then use
> git-subtree pull to keep yourself updated.
> 


well... yes, but releases are marked by tags, not branches so what I really want is a tag.

I still use git so I have the possibility to update and can traceback what happened later

> e.g.
> 
> To add:
> 
> git subtree add --prefix=$subdir $repo $branch
> 
> Then to update:
> 
> git subtree pull --prefix=$subdir $repo $branch
> 


ok, that probably works with branches (didn't test)

> If you make any changes on the branch and wanted to push them back
> you
> could do that with:
> 
> git subtree pull --prefix=$subdir $repo2 $branch2
> 
> $repo2 and $branch2 would be different from $repo and $branch if you
> wanted to push to your own fork before submitting a pull request.
> 

shouldn't there be a subtree split somewhere ? IIUC pull is only merge from the remote to my local repo,
not the other way round


> --
> Paul [W] Campbell
> 

Re: Questions/investigations on git-subtree and tags

[Paul Campbell]

On Thu, Mar 7, 2013 at 11:05 AM, Jeremy Rosen <jeremy.rosen@openwide.fr> wrote:
>>
>> Hi Jérémy,
>>
>> Git subtree ignores tags from the remote repo.
>>
>
> is that a design decision or a case of "not implemented yet"

I'm not sure. If you imported all the tags from all your subtrees
repos, you could easily end up with duplicate tags from different
repos. They could be namespaced, but there is no concept of namespace
in git-subtree. That even assumes that you can tag a subtree (I've not
tried).

>> To follow a project in a subdirectory I would use git-subtree add
>> selecting a branch, not a tag, from the other repo. Then use
>> git-subtree pull to keep yourself updated.
>>
>
>
> well... yes, but releases are marked by tags, not branches so what I really want is a tag.
>
> I still use git so I have the possibility to update and can traceback what happened later
>
>> e.g.
>>
>> To add:
>>
>> git subtree add --prefix=$subdir $repo $branch
>>
>> Then to update:
>>
>> git subtree pull --prefix=$subdir $repo $branch
>>
>
>
> ok, that probably works with branches (didn't test)
>
>> If you make any changes on the branch and wanted to push them back
>> you
>> could do that with:
>>
>> git subtree pull --prefix=$subdir $repo2 $branch2
>>
>> $repo2 and $branch2 would be different from $repo and $branch if you
>> wanted to push to your own fork before submitting a pull request.
>>
>
> shouldn't there be a subtree split somewhere ? IIUC pull is only merge from the remote to my local repo,
> not the other way round

Oops, that should have been git subtree push, which uses git subtree
split internally.

-- 
Paul [W] Campbell

Re: Questions/investigations on git-subtree and tags

[Jeremy Rosen]

> >>
> >> Git subtree ignores tags from the remote repo.
> >>
> >
> > is that a design decision or a case of "not implemented yet"
> 
> I'm not sure. If you imported all the tags from all your subtrees
> repos, you could easily end up with duplicate tags from different
> repos. They could be namespaced, but there is no concept of namespace
> in git-subtree. That even assumes that you can tag a subtree (I've
> not
> tried).
> 

Ok, I can understand that you don't want to import tags for namespace reason, but in that case shouldn't 
git subtree add refuse to create a subtree when the tag isn't a commit

or if it allows it, what would be the gracefull way to handle that ?

i'm quite new to git's internals, so I don't really know if/what the right approch would be.

note that all those problems seems to disapear when squash is not used

Re: Questions/investigations on git-subtree and tags

[Paul Campbell]

On Thu, Mar 7, 2013 at 12:50 PM, Jeremy Rosen <jeremy.rosen@openwide.fr> wrote:
>> >>
>> >> Git subtree ignores tags from the remote repo.
>> >>
>> >
>> > is that a design decision or a case of "not implemented yet"
>>
>> I'm not sure. If you imported all the tags from all your subtrees
>> repos, you could easily end up with duplicate tags from different
>> repos. They could be namespaced, but there is no concept of namespace
>> in git-subtree. That even assumes that you can tag a subtree (I've
>> not
>> tried).
>>
>
> Ok, I can understand that you don't want to import tags for namespace reason, but in that case shouldn't
> git subtree add refuse to create a subtree when the tag isn't a commit

It shouldn't and tries not to, but is limited in it's ability to
identify if a refspec points to a commit or not in the remote repo.

> or if it allows it, what would be the gracefull way to handle that ?

I've posted a patch (which is pending a lot of other changes to
git-subtree that I'm corralling) that tries to prevent some obvious
errors in the refspec. But letting the git fetch used by git-subtree
add and git-subtree pull catch the error and report it may be the best
option.

> i'm quite new to git's internals, so I don't really know if/what the right approch would be.
>
> note that all those problems seems to disapear when squash is not used

I've never really tried using --squash, I don't see that it adds any
value for me.

-- 
Paul [W] Campbell

Re: Questions/investigations on git-subtree and tags

[Jeremy Rosen]

> >
> > Ok, I can understand that you don't want to import tags for
> > namespace reason, but in that case shouldn't
> > git subtree add refuse to create a subtree when the tag isn't a
> > commit
> 
> It shouldn't and tries not to, but is limited in it's ability to
> identify if a refspec points to a commit or not in the remote repo.
> 

ok, i've studied a little more

* the target for "git subtree add <url> <refspec> can only be a remote branch or tag, since we git fetch 
can only target remote refs.
* in case of a branch, git subtree forgets the branch and only use the commit linked to the branch. for 
tags, the fetch part is ok, it's the merge part that fail. adding ^{} at the right place would probably fix that


> 
> I've posted a patch (which is pending a lot of other changes to
> git-subtree that I'm corralling) that tries to prevent some obvious
> errors in the refspec. But letting the git fetch used by git-subtree
> add and git-subtree pull catch the error and report it may be the
> best
> option.
> 

that's interesting... do you have a link ? 


> 
> I've never really tried using --squash, I don't see that it adds any
> value for me.
> 

my project has a git subtree for a linux kernel and another subtree for buildroot, 

a default .git is about 1.5G, squashing it reduces it to 200M so it's worth it for me :)

Re: Questions/investigations on git-subtree and tags

[Paul Campbell]

On Thu, Mar 7, 2013 at 3:15 PM, Jeremy Rosen <jeremy.rosen@openwide.fr> wrote:
>> >
>> > Ok, I can understand that you don't want to import tags for
>> > namespace reason, but in that case shouldn't
>> > git subtree add refuse to create a subtree when the tag isn't a
>> > commit
>>
>> It shouldn't and tries not to, but is limited in it's ability to
>> identify if a refspec points to a commit or not in the remote repo.
>>
>
> ok, i've studied a little more
>
> * the target for "git subtree add <url> <refspec> can only be a remote branch or tag, since we git fetch
> can only target remote refs.
> * in case of a branch, git subtree forgets the branch and only use the commit linked to the branch. for
> tags, the fetch part is ok, it's the merge part that fail. adding ^{} at the right place would probably fix that

I think I tried adding the ^{} syntax, but I don't think it works on
remote repos. Or I couldn't get the right syntax.

>>
>> I've posted a patch (which is pending a lot of other changes to
>> git-subtree that I'm corralling) that tries to prevent some obvious
>> errors in the refspec. But letting the git fetch used by git-subtree
>> add and git-subtree pull catch the error and report it may be the
>> best
>> option.
>>
>
> that's interesting... do you have a link ?

Latest patch:

  http://thread.gmane.org/gmane.comp.version-control.git/217257

Prior patch with comments from Junio on what was probably going on
with the old tests:

  http://thread.gmane.org/gmane.comp.version-control.git/217227

>>
>> I've never really tried using --squash, I don't see that it adds any
>> value for me.
>>
>
> my project has a git subtree for a linux kernel and another subtree for buildroot,
>
> a default .git is about 1.5G, squashing it reduces it to 200M so it's worth it for me :)

If disk space is the issue, or bandwidth for initial cloning, then
sure, but I thought Git was efficient enough that a large repo
wouldn't give much of a performance hit.  Unless you use git-subtree
split or push, they are slow.

If git-subtree split could be optimised then --squash wouldn't be
needed as much. It does take an age compared to other Git operations.

-- 
Paul [W] Campbell

Re: Questions/investigations on git-subtree and tags

[Jeremy Rosen]

> 
> I think I tried adding the ^{} syntax, but I don't think it works on
> remote repos. Or I couldn't get the right syntax.
> 

indeed, it doesn't work on fetch, but it could be used somewhere between the fetch and the commit-tree to move from the ref to the associated commit




> 
> Latest patch:
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/217257
> 

oh, that patch, yes I found it while looking around it is a step in the right direction but it doesn't help in my case since i'm using a valid remote ref that can be fetched

(on a side note you could use git ls-remote to check for the remote ref and avoid a fetch in case of an incorrect ref, but that's just a detail)



I just tested with it and here is what happens

git subtree add --squash -P br2 git://git.buildroot.net/buildroot 2013.02 => works ok, br2 is created

however the message of the squash commit is 


    Squashed 'br2/' content from commit f1d2c19
    
    git-subtree-dir: br2
    git-subtree-split: f1d2c19091e1c2ef803ec3267fe71cf6ce7dd948


which is not correct :

git ls-remote git://git.buildroot.net/buildroot 2013.02
f1d2c19091e1c2ef803ec3267fe71cf6ce7dd948	refs/tags/2013.02

git ls-remote git://git.buildroot.net/buildroot 2013.02^{}
15ace1a845c9e7fc65b648bbaf4dd14e03d938fd	refs/tags/2013.02^{}


as you can see git subtee thinks it splited from the tag SHA instead of the tag's commit SHA

this is incorrect because the tag isn't here, and at split time git subtree won't be able to find the correct ancestor. We just need to make sure we use the tag's commit instead
of the tag



changing
	revs=FETCH_HEAD
to
	revs=FETCH_HEAD^{}
in cmd_add_repository

seems to fix it, both for remote branch pull and remote tag pull


we still have a bug lurking around it's the case where the user does the fetch himself then use subtree add with a tag SHA. but let's discuss problems one at a time :)

Re: Questions/investigations on git-subtree and tags

[Jeremy Rosen]

[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]

ok, attached is a patch on top of your patch that solves my particular
problem

I am not "formally submitting it" since its on top of your part and i'd
really like your input before submitting.

It solves my problem and afaict does what your fix did and what git-subtree
originally intended to do...

tell me what you think

    Cordialement

    Jérémy Rosen

fight key loggers : write some perl using vim

----- Mail original -----
> > 
> > I think I tried adding the ^{} syntax, but I don't think it works
> > on
> > remote repos. Or I couldn't get the right syntax.
> > 
> 
> indeed, it doesn't work on fetch, but it could be used somewhere
> between the fetch and the commit-tree to move from the ref to the
> associated commit
> 
> 
> 
> 
> > 
> > Latest patch:
> > 
> >   http://thread.gmane.org/gmane.comp.version-control.git/217257
> > 
> 
> oh, that patch, yes I found it while looking around it is a step in
> the right direction but it doesn't help in my case since i'm using a
> valid remote ref that can be fetched
> 
> (on a side note you could use git ls-remote to check for the remote
> ref and avoid a fetch in case of an incorrect ref, but that's just a
> detail)
> 
> 
> 
> I just tested with it and here is what happens
> 
> git subtree add --squash -P br2 git://git.buildroot.net/buildroot
> 2013.02 => works ok, br2 is created
> 
> however the message of the squash commit is
> 
> 
>     Squashed 'br2/' content from commit f1d2c19
>     
>     git-subtree-dir: br2
>     git-subtree-split: f1d2c19091e1c2ef803ec3267fe71cf6ce7dd948
> 
> 
> which is not correct :
> 
> git ls-remote git://git.buildroot.net/buildroot 2013.02
> f1d2c19091e1c2ef803ec3267fe71cf6ce7dd948	refs/tags/2013.02
> 
> git ls-remote git://git.buildroot.net/buildroot 2013.02^{}
> 15ace1a845c9e7fc65b648bbaf4dd14e03d938fd	refs/tags/2013.02^{}
> 
> 
> as you can see git subtee thinks it splited from the tag SHA instead
> of the tag's commit SHA
> 
> this is incorrect because the tag isn't here, and at split time git
> subtree won't be able to find the correct ancestor. We just need to
> make sure we use the tag's commit instead
> of the tag
> 
> 
> 
> changing
> 	revs=FETCH_HEAD
> to
> 	revs=FETCH_HEAD^{}
> in cmd_add_repository
> 
> seems to fix it, both for remote branch pull and remote tag pull
> 
> 
> we still have a bug lurking around it's the case where the user does
> the fetch himself then use subtree add with a tag SHA. but let's
> discuss problems one at a time :)
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gst.diff --]
[-- Type: text/x-patch; name=gst.diff, Size: 479 bytes --]

506,513c506,507
< 		case "$2" in
< 		*\**) # Avoid pulling in multiple branches
< 			die "'$2' contains a wildcard"
< 			;;
< 		*:*) # Don't create a local branch for the subtree
< 			die "'$2' contains a local branch name"
< 			;;
< 		esac
---
> 		git ls-remote --exit-code $1 $2 ||
> 		die "'$2' is not a correct reference on '$1'"
535c529
< 	revs=$(git rev-parse $default --revs-only "$@") || exit $?
---
> 	revs=$(git rev-parse $default --revs-only "$1^{commit}") || exit $?

Re: Questions/investigations on git-subtree and tags

[Junio C Hamano]

Jeremy Rosen <jeremy.rosen@openwide.fr> writes:

> 506,513c506,507
> < 		case "$2" in
> < 		*\**) # Avoid pulling in multiple branches
> < 			die "'$2' contains a wildcard"
> < 			;;
> < 		*:*) # Don't create a local branch for the subtree
> < 			die "'$2' contains a local branch name"
> < 			;;
> < 		esac
> ---
>> 		git ls-remote --exit-code $1 $2 ||

You would need to quote $1 and $2 properly to prevent the shell from
splitting them into words, no?

>> 		die "'$2' is not a correct reference on '$1'"

> 535c529
> < 	revs=$(git rev-parse $default --revs-only "$@") || exit $?
> ---
>> 	revs=$(git rev-parse $default --revs-only "$1^{commit}") || exit $?

Is it guaranteed that your $# is 1 at this point, or is it something
you would also need to check here, or perhaps in the caller of this
function (I cannot tell offhand in a patch without any context)?

Re: Questions/investigations on git-subtree and tags

[Jeremy Rosen]

----- Mail original -----
> Jeremy Rosen <jeremy.rosen@openwide.fr> writes:
> 
> > 506,513c506,507
> > < 		case "$2" in
> > < 		*\**) # Avoid pulling in multiple branches
> > < 			die "'$2' contains a wildcard"
> > < 			;;
> > < 		*:*) # Don't create a local branch for the subtree
> > < 			die "'$2' contains a local branch name"
> > < 			;;
> > < 		esac
> > ---
> >> 		git ls-remote --exit-code $1 $2 ||
> 
> You would need to quote $1 and $2 properly to prevent the shell from
> splitting them into words, no?
> 

yes... I'm not very good at shell programming, good catch

> >> 		die "'$2' is not a correct reference on '$1'"
> 
> > 535c529
> > < 	revs=$(git rev-parse $default --revs-only "$@") || exit $?
> > ---
> >> 	revs=$(git rev-parse $default --revs-only "$1^{commit}") || exit
> >> 	$?
> 
> Is it guaranteed that your $# is 1 at this point, or is it something
> you would also need to check here, or perhaps in the caller of this
> function (I cannot tell offhand in a patch without any context)?
> 

I have checked the call sites and yes we can only have one arguement at
this point. so the $@ to $1 is more about future-proofing and readability


thx for proofreading

Re: Questions/investigations on git-subtree and tags

[Jeremy Rosen]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

Paul, I'm not quite sure where I should go from here...

should I send you a patch so you make it a V3 of your patch ? should I
send a patch superseeding yours ? 

I have also found a similar problem in git-subtree pull, which needs 
the same fix. 

in the mean time, attached is the current version of my changes

    Cordialement

    Jérémy Rosen

fight key loggers : write some perl using vim


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-git-subtree-make-sure-the-SHA-saved-as-ancestor-is-a.patch --]
[-- Type: text/x-patch; name=0001-git-subtree-make-sure-the-SHA-saved-as-ancestor-is-a.patch, Size: 1343 bytes --]

From 12490724ae955719694d825dff4fa9e0d2709c1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Rosen?= <jeremy.rosen@openwide.fr>
Date: Tue, 12 Mar 2013 10:56:54 +0100
Subject: [PATCH 1/2] git-subtree: make sure the SHA saved as ancestor is a
 commit
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When adding or merging the first parameter might not be a commit, it can also be a tag SHA.
This needs to be fixed by using the underlying commit or the ancestor finding code will croak at split time


Signed-off-by: Jérémy Rosen <jeremy.rosen@openwide.fr>
---
 contrib/subtree/git-subtree.sh |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 8a23f58..8b9d114 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -531,7 +531,7 @@ cmd_add_repository()
 
 cmd_add_commit()
 {
-	revs=$(git rev-parse $default --revs-only "$@") || exit $?
+	revs=$(git rev-parse $default --revs-only "$1^{commit}") || exit $?
 	set -- $revs
 	rev="$1"
 	
@@ -655,7 +655,7 @@ cmd_split()
 
 cmd_merge()
 {
-	revs=$(git rev-parse $default --revs-only "$@") || exit $?
+	revs=$(git rev-parse $default --revs-only "$1^{commit}") || exit $?
 	ensure_clean
 	
 	set -- $revs
-- 
1.7.10.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-git-subtree-use-ls-remote-to-check-the-refspec-passe.patch --]
[-- Type: text/x-patch; name=0002-git-subtree-use-ls-remote-to-check-the-refspec-passe.patch, Size: 1628 bytes --]

From 05d1dd56217be59d69952a41d97e204cc7821948 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Rosen?= <jeremy.rosen@openwide.fr>
Date: Tue, 12 Mar 2013 10:57:56 +0100
Subject: [PATCH 2/2] git-subtree: use ls-remote to check the refspec passed
 to pull and add
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

ls-remote is the correct way to check that a parameter is a valid fetchable target


Signed-off-by: Jérémy Rosen <jeremy.rosen@openwide.fr>
---
 contrib/subtree/git-subtree.sh |   11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 8b9d114..61d4eab 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -503,13 +503,8 @@ cmd_add()
 
 	    "cmd_add_commit" "$@"
 	elif [ $# -eq 2 ]; then
-	    # Technically we could accept a refspec here but we're
-	    # just going to turn around and add FETCH_HEAD under the
-	    # specified directory.  Allowing a refspec might be
-	    # misleading because we won't do anything with any other
-	    # branches fetched via the refspec.
-	    git rev-parse -q --verify "$2^{commit}" >/dev/null ||
-	    die "'$2' does not refer to a commit"
+		git ls-remote --exit-code "$1" "$2" ||
+		die "'$2' is not a correct reference on '$1'"
 
 	    "cmd_add_repository" "$@"
 	else
@@ -700,6 +695,8 @@ cmd_merge()
 cmd_pull()
 {
 	ensure_clean
+	git ls-remote --exit-code "$1" "$2" ||
+		die "'$2' is not a correct reference on '$1'"
 	git fetch "$@" || exit $?
 	revs=FETCH_HEAD
 	set -- $revs
-- 
1.7.10.4

Re: Questions/investigations on git-subtree and tags

[Paul Campbell]

On Tue, Mar 12, 2013 at 10:02 AM, Jeremy Rosen <jeremy.rosen@openwide.fr> wrote:
> Paul, I'm not quite sure where I should go from here...
>
> should I send you a patch so you make it a V3 of your patch ? should I
> send a patch superseeding yours ?
>
> I have also found a similar problem in git-subtree pull, which needs
> the same fix.
>
> in the mean time, attached is the current version of my changes
>
>     Cordialement
>
>     Jérémy Rosen
>
> fight key loggers : write some perl using vim
>

Thanks Jérémy.

Nothing in your patches are dependant on anything I'm working on. I'll
gladly take them for my own tree but feel free to submit them (inline,
rather than as attachments) to the list and cc: David Greene
<greened@obbligato.org> the subtree area maintainer.

-- 
Paul [W] Campbell