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

[Jeff King <peff@peff.net>]

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

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

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

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

> 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