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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 27, 2009, 22:33 UTC
Message-ID: <7vaazc31sj.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20091027014525.GA29583@sigio.peff.net>

Jeff King <peff@peff.net> writes:

Show 22 quoted lines

> On Mon, Oct 26, 2009 at 04:31:57PM -0700, Junio C Hamano wrote:
>
>> 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.
>
> OK, I agree.
>
>> 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.
>
> The thing is that I can't think of another sensible place. And this
> sensible place is useful for one particular action: renaming a remote
> branch, like this:
>
>   $ git fetch ;# presumably gets origin/branch
>   $ git push origin/branch:renamed-branch
>
> which is much nicer than exposing clueless users to
> ":refs/heads/renamed-branch".

You would need to expose ":refs/heads/branch" to make this a rename, not a copy, wouldn't you?

Show 11 quoted lines

>> 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
>
> I'm not sure why it's likely to be a mistake.
> ...
> Am I missing some part of your argument?

I do not see much point (other than your "rename" example) in pushing what you got from the other end without changing anything yourself back to the same remote.

There was a thread in which people argued that the primary thing that is dangerous in this sequence

    $ git checkout origin/next; work-commit; work-commit; ...

is when you leave the detached HEAD state without saving it to a local branch. I think what is more dangerous is that it will not give the user a solid understanding that these commits do _not_ change origin/next in any way. After doing the above, it is understandable that a novice would mistakenly think: "I started from origin/next and built some, let's push the result".

	Side note: This is the reason why I think Dscho's "git checkout
        next" that dwims to "-t -b next origin/next" is OK (perhaps on the
        right side of the borderline), because it is more clear that this
        is about creating and using your own "next", compared to the
        existing "-t origin/next" shorthand.  The latter risks imprinting
        a misconception on an uninitiated that we are somehow working on
        origin/next.

With such a misconception, you will see the likely mistake here, too:

    $ git push origin origin/next:refs/heads/next

If "rename" is the _only_ valid reason you might want to push what you got from there back to the same remote, _and_ if "rename" is something very often needed, I think we would prefer to have a way to support that operation directly, instead of more general DWIM that would risk passing mistakes like the above unwarned.

> ...  But I'm not sure why
> you would accidentally provide something in refs/remotes, or not want to
> be pushing to refs/heads. Where _else_ do you push, except for tags?

The above "checking out origin/next" illustrates the mistake on the $src side, not on the $dst side. That's why my alternative solution in the previous message was to see the type of $src and push commits to local branches, exactly because "where else do you push".

IOW, it's between "prevent push with dubious $src from happening in the first place" vs "give them rope". Historically I always sided with the latter camp, but I am trying to play a devil's advocate for a change ;-).