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

[Salikh Zakirov <Salikh.Zakirov@Intel.com>]

Junio C Hamano wrote:
> -- >8 --
> [PATCH] refs outside refs/{heads,tags} match less strongly.
> 
> Pushing 'foo' when both heads/foo and tags/foo exist at the
> remote end is still considered an error and you would need to
> disambiguate between them by being more explicit.
> 
> When neither heads/foo nor tags/foo exists at the remote,
> pushing 'foo' when there is only remotes/origin/foo is not
> ambiguous, while it still is ambiguous when there are more than
> one such weaker match (remotes/origin/foo and remotes/alt/foo,
> for example).

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

              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.

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?