Re: [PATCH] push: support remote branches in guess_ref DWIM

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 26, 2009, 23:31 UTC
Message-ID: <7v8wexn34i.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20091026213353.GA27871@sigio.peff.net>

Jeff King <peff@peff.net> writes:

Show 17 quoted lines

> When we get an unqualified dest refspec like "foo", we try
> to guess its full ref path (like "refs/heads/foo") based on
> the source ref. Commit f8aae12 mapped local heads to remote
> heads, and local tags to remote tags.
>
> This commit maps local tracking branches under
> "refs/remotes" to remote branch heads, so
>
>   git push origin origin/branch:renamed-branch
>
> pushes to refs/heads/renamed-branch.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This came from a discussion on IRC. I don't see any reason not to do
> this; would people really expect it to push into refs/remotes/ on the
> other side (right now, it complains and dies)?

As _our_ origin can never be _their_ origin if we are clone of them, I do not think anybody sane would expect it to push into refs/remotes/origin/ to begin with.

But "not in refs/remotes/" does not automatically mean "the only sensible place is refs/heads", does it? "We do not know what kind of mistake the user is trying to make" could be more plausible answer, and in that case, "complain and die" may be a more valid course of action.

For example,

    git push origin origin/master:refs/heads/master

is most likely to be a mistake. The only situation something similar to this makes sense is where you pushed out a bogus commit earlier and are trying to correct it perhaps with

	git push origin +origin/master@{1}:refs/heads/master

but you need to force it and go back in the reflog.

I know you are doing this DWIM only when $dst does not exist over there, and the "pushing old master back to master" above is a different scenario, but if "git push origin origin/master:master" shouldn't update their local master, "git push origin origin/master:naster" shouldn't update their local naster, in order to avoid confusion arising from inconsistency, no?

Another possibility is to see the type (not refname) of $src and push all commits to refs/heads/$dst and everything else (most likely tags) to refs/tags/$dst, to simplify the rule to make it easier to explain and remember, but there are lightweight tags that make this idea unworkable.

Show 7 quoted lines

> A related issue (which exists even without this patch) is that doing
> this:
>
>   master:remotes/incoming/master
>
> will create "refs/heads/remotes/incoming/master". Perhaps we should DWYM
> a little more and recognize "heads", "remotes", and "tags" as special.

Yes, it is an independent issue; I think correcting this DWIM (or at least "warning" if not refusing to create remotes/ under refs/heads/) might be a good idea.