Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Miles Bader" <miles@xxxxxxx> writes: > > > Maybe I"m weird, but I tend to think of the refs/... syntax as being > > for "only if you're doing something funny" cases. > > It is just nobody felt strong enough reason to sugarcoat the > normalized syntax with something like: > > git push --create remote foo v1.2.0 > > You can be a hero by updating git-push to take such, and make it > interpret as if the user passed the normalized syntax which is: > > git push remote foo:refs/heads/foo v1.2.0:refs/tags/v1.2.0 Actually git push remote foo v1.2.0 already expands that way today, without the --create logic you are talking about introducing. Its part of the DWIM-ery of today's git-push. Yes, really, you don't even need to say "tag v1.2.0" to create the tag v1.2.0 on the remote side. Where people run into problems is when they want to rename the branch during push and create the new name on the remote. Our remote-side matching logic works sometimes (when there is a matching name on the remote side) and not others (when there is not a matching name). That can be very confusing. E.g. users want to be able to do something such as: git push remote experimental:pu and just have refs/heads/pu be created because experimental is also a branch in the local repository and pu does not exist on the remote side. There is of course the workaround of: git branch -m experimental pu git push remote pu git branch -m pu experimental but that's really really annoying to have to use to make git-push DWIM. Users expect this to work because it does if refs/heads/pu already exists on the remote. For many workflows it is also more common for branches to exist on the remote and just need updating than it is for for them to be created new; consequently users see the "rename during push" magic Just Work(tm). Then when it fails during remote side branch creation Git is instantly the Goddamn Idotic Truckload of s**t. :-\ -- Shawn. - 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
