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?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html