Re: git-push branch confusion caused by user mistake

["Jakub Narębski" <jnareb@gmail.com>]

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