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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html