@HaraldNordgren wait, I do have a use case for those. Empty subsections allow "dotted aliases" like git .r. I think you will need a much more compelling cover letter if you want to defend this idea to render those existing use cases dysfunctional.

Thanks @dscho!

Is alias special here, so we could run this for every other case you think?

Thanks @dscho!

Is alias special here, so we could run this for every other case you think?

You could special-case alias. But I don't think that this kind of complicating things serves us well. Exhibit A: Git itself. Look at the many special-casings that all had merit, and cumulatively result in this horribly inconsistent user experience. "It's easy! Just do X. Except in case B, do Y. And if that fails because of C, do X again, then it'll work! Easy." Same here. "This is prohibited". "But why does it work with aliases?" "Because aliases are special." "That makes no sense!" "Well, it is what it is." Is the kind of frustrating conversation I foresee if you push this through. Git is full of these convoluted argumentations. Let's not make it worse.

@dscho I ran this and all of a sudden my git status was broken.

I could fix it, but can we really expect a new user to handle this?

❯ git config branch.$(rev-parse --abbrev-ref HEAD).pushRemote upstream # Forgot 'git' before rev-parse
zsh: command not found: rev-parse

❯ git status
On branch fetch-prune-local-branches
fatal: bad config variable 'branch..pushremote' in file '.git/config' at line 274

❯ git config branch.$(rev-parse --abbrev-ref HEAD).pushRemote upstream # Forgot 'git' before rev-parse
zsh: command not found: rev-parse

Rather than encouraging such invocations, why not make life with Git simpler for a change and implement a companion of the git branch --set-upstream-to option?

No amount of added complexity in Git can prevent complicated command-lines from being footguns for the user. Therefore, I would like to encourage you to optimize for improved user experience and footgun reduction rather than for complicated command-lines.

@dscho That's a interesting idea!

So --set-upstream-to updates the config itself? I never thought about that!

So --set-upstream-to updates the config itself?

It sure does :-)

@dscho Thinking about this again, branch is not special in this case so implementing a --set-push-remote-to doesn't solve the core issue.

My point was that a user can easily set a config that will break their setup. I wonder if even alias should be treated specially. I guess that a user that needs that can set it themselves via config?

No amount of added complexity in Git can prevent complicated command-lines from being footguns for the user.

One step at a time we can make Git better for everyone 😃