On Fri, 24 Nov 2006 13:14:00 +0300 Salikh Zakirov wrote:
> git-push.1 has following description:
>
> Some short-cut notations are also supported.
>
> o tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>.
BTW, this is broken (and was broken even in 1.4.3.x):
$ mkdir ~/tmp/test_repo
$ ( cd ~/tmp/test_repo; git-init-db )
defaulting to local storage area
$ git push ~/tmp/test_repo tag v1.4.4.1
error: src refspec tag does not match any.
error: dst refspec tag does not match any existing ref on the remote and does not start with refs/.
fatal: unexpected EOF
Omitting the "tag" word works:
$ git push ~/tmp/test_repo v1.4.4.1
updating 'refs/tags/v1.4.4.1'
from 0000000000000000000000000000000000000000
to 21dff5f4982333d694d105595a701540d4d0d1db
Generating pack...
Done counting 28130 objects.
Deltifying 28130 objects.
100% (28130/28130) done
Writing 28130 objects.
100% (28130/28130) done
Total 28130, written 28130 (delta 19344), reused 27628 (delta 18891)
refs/tags/v1.4.4.1: 0000000000000000000000000000000000000000 -> 21dff5f4982333d694d105595a701540d4d0d1db
Seems that nobody really uses the "tag NAME" syntax...
> o A parameter <ref> without a colon is equivalent to
> <ref>:<ref>, hence updates <ref> in
> the destination from <ref> in the source.
>
> Maybe this is only my reading of manual page, but I understood
> it like it does not leave the room for ambiguity, because it is using
> _the same_ refspec as the local one.
>
> That's why, when I do
>
> git-push repo x
>
> and it results in
>
> git-push repo refs/heads/x:refs/remotes/origin/x
>
> instead of expected
>
> git-push repo refs/heads/x:refs/heads/x
>
> just because the remote repo did not have refs/heads/x, but happened
> to have refs/remotes/origin/x, would be highly surprising to me.
Such interpretation would indeed be horrible, but I'm afraid this is
exactly the case now:
$ mkdir ~/tmp/test_repo
$ ( cd ~/tmp/test_repo; git-init-db )
defaulting to local storage area
$ git push ~/tmp/test_repo v1.4.0^0:refs/remotes/origin/master
updating 'refs/remotes/origin/master' using 'v1.4.0^0'
from 0000000000000000000000000000000000000000
to 41292ddd37202ff6dce34986c87a6000c5d3fbfa
Generating pack...
Done counting 19857 objects.
Deltifying 19857 objects.
100% (19857/19857) done
Writing 19857 objects.
100% (19857/19857) done
Total 19857, written 19857 (delta 13472), reused 19038 (delta 12884)
refs/remotes/origin/master: 0000000000000000000000000000000000000000 -> 41292ddd37202ff6dce34986c87a6000c5d3fbfa
$ git push ~/tmp/test_repo master
updating 'refs/remotes/origin/master' using 'refs/heads/master'
from 41292ddd37202ff6dce34986c87a6000c5d3fbfa
to e945f95157c2c515e763ade874931fc1eb671a0b
Generating pack...
Done counting 8667 objects.
Result has 8278 objects.
Deltifying 8278 objects.
100% (8278/8278) done
Writing 8278 objects.
100% (8278/8278) done
Total 8278, written 8278 (delta 5924), reused 7396 (delta 5065)
refs/remotes/origin/master: 41292ddd37202ff6dce34986c87a6000c5d3fbfa -> e945f95157c2c515e763ade874931fc1eb671a0b
BTW, I cannot find the description of the matching algorithm used by
connect.c:count_refspec_match() anywhere in the git-push or git-fetch
man page, and I cannot understand why this algorithm is different from
the default search order ($name, refs/$name, refs/tags/$name,
refs/heads/$name, refs/remotes/$name, refs/remotes/$name/HEAD).
> The expected behaviour on 'git-push repo x' in my understanding is
> 1) git finds the exact reference for 'x' (i.e. either refs/heads/x or
> refs/tags/x) according to local lookup rules
> 2) git uses the found reference _unambiguously_ to create or update
> exactly the same reference in the remote repo.
>
> Am I the only one to have this understanding?
The problem is that "$x" and "$x:$x" would be not equivalent anymore,
unless we add a special case for "$x:$y" where $x == $y - hmm, but the
current code seems to have that special case:
else if (!strcmp(rs[i].src, rs[i].dst) &&
matched_src) {
/* pushing "master:master" when
* remote does not have master yet.
*/
(but that code triggers only in case we did not find any matching ref in
the destination repo).
Attachment:
pgp4tHHQFBIrg.pgp
Description: PGP signature