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

From: Jeff King <peff@peff.net>
Date: Oct 28, 2009, 00:01 UTC
Message-ID: <20091028000104.GA9426@sigill.intra.peff.net>
In-Reply-To: <7vaazc31sj.fsf@alter.siamese.dyndns.org>

On Tue, Oct 27, 2009 at 03:33:16PM -0700, Junio C Hamano wrote:

Show 8 quoted lines

> >   $ 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?

Yeah, you're right. This was based on an actual user request, and I didn't think too closely about the other steps. But since the deletion is of an existing branch, you should be able to do that without refs/heads. So:

  $ git push origin origin/branch:renamed-branch
  $ git push origin :branch

Which of course you could do in one command if you wanted to live (more) dangerously.

Show 5 quoted lines

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

I don't either; my hope was that we can make that case a little bit easier without creating undue hardship for anybody else.

Show 11 quoted lines

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

I suppose it's possible. I don't have any evidence that users actually think that way.

Show 9 quoted lines

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

OK, I can buy that. It would be much nicer even to support explicit renaming (in fact, the user request started with that, and I just didn't want to give them an answer that involved refs/heads/, which I think is unnecessarily scary to users).

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

Heh. Thanks for explaining your thinking.

Let's scrap this for now, then. Remote rename doesn't actually come up very often, and I agree that it would be nice to have an actual atomic movement, which is what people really want.

-Peff