Re: [PATCH] Make git-clone --use-separate-remote the default

[Sergey Vlasov <vsu@altlinux.ru>]

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

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 #2: Type: application/pgp-signature, Size: 189 bytes --]