Re: Questions/investigations on git-subtree and tags

[Jeremy Rosen <jeremy.rosen@openwide.fr>]

[-- 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 $?