Re: git-push branch confusion caused by user mistake
- Date: Sat, 11 Mar 2017 21:43:34 +0100
- From: Jakub Narębski <jnareb@xxxxxxxxx>
- Subject: Re: git-push branch confusion caused by user mistake
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
$ 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:
> => 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.