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

[Jeff King <peff@peff.net>]

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

> 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. I've given the one use
case I can think of where you _do_ want to do it. 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?

Am I missing some part of your argument?

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

OK, I'll try to work up a patch.

-Peff