Jeff King <peff@xxxxxxxx> writes:
> 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?
>> 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 ;-).
--
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