W dniu 10.03.2017 o 22:44, Phil Hord pisze:
> This week a user accidentally did this:
>
> $ git push origin origin/master
> Total 0 (delta 0), reused 0 (delta 0)
> To parent.git
> * [new branch] origin/master -> origin/master
>
> He saw his mistake when the "new branch" message appeared, but he was
> confused about how to fix it and worried he broke something.
It is nowadays very easy to delete accidentally created remote branch
with
$ git push origin --delete origin/master
> It seems reasonable that git expanded the original args into this one:
>
> git push origin refs/remotes/origin/master
>
> However, since the dest ref was not provided, it was assumed to be the
> same as the source ref, so it worked as if he typed this:
>
> git push origin refs/remotes/origin/master:refs/remotes/origin/master
This rule depends on push.default setting, but it is a very simple
rule. Simple is good. DWIM is usually not worth it, unless program
can guess what you meant, and what you meant is always the same.
> I think git should be smarter about deducing the dest ref from the
> source ref if the source ref is in refs/remotes, but I'm not sure how
> far to take it. It feels like we should translate refspecs something
> like this for push:
>
> origin/master
> => refs/remotes/origin/master:refs/heads/master
[...]
Such push doesn't make sense (unless you have a quite unusual situation).
Note that 'origin/master', that is 'refs/remotes/origin/master' is a
remote-tracking branch, that is a ref that is meant to track position
of the 'master' branch ('refs/heads/master') in the 'origin' remote.
Thus it should always be the same as 'master' in 'origin', or be behind
if you didn't fetch.
> Does this seem reasonable? I can try to work up a patch if so.
Thus I don't think such complication is reasonable.
--
Jakub Narębski