3 ms·
> Complaining about git's standard porcelain is a popular sport, but so often the people who play it don't give proposals that make more sense than the status q
by dap 13y ago
> Complaining about git's standard porcelain is a popular sport, but so often the people who play it don't give proposals that make more sense than the status quo.
This is a classic case where the git behavior seems not just unintuitive, but far more complicated than necessary. Why do multiple modes even exist? If I were starting, I'd consider saying that "git push" with no other arguments is the same as what "current" (or even "simple") do now, but you could specify any number of branches or branch wildcards with an argument (including "*"). That is, like ls(1).
I could definitely be missing some important class of use cases, but this feels so much simpler than even having modes, let alone modes that have complex semantics, and still lets the default (very common) case work and supports pushing a manually-specified set of branches, too.
- jlgreco 13y agopush.default Defines the action git push should take if no refspec is given on the command line, no refspec is configured in the remote, and no refspec is implied by any of the options given on the command line. Possible values are: · nothing - do not push anything. · matching - push all matching branches. All branches having the same name in both ends are considered to be matching. This is the default. · upstream - push the current branch to its upstream branch. · tracking - deprecated synonym for upstream. · current - push the current branch to a branch of the same name. (yes, my version of git on this machine is out of date) Emphasis on: "if no refspec is given on the command line, no refspec is configured in the remote, and no refspec is implied by any of the options given on the command line" These modes define what happens if you give no options to git-push. If these modes didn't exist, then you would instead be complaining that a plain old `git push` with no arguments didn't "do what you clearly meant" (where "clearly meant" changes from user to user... particularly since different users have different workflows, some centralized, some not.) If git-push worked as you suggest, then you would just be complaining that you had to escape your asterisks characters to prevent the shell from expanding them (remember that glob expansion is not something that ls provides...), instead of using a far simpler --all. You want a legitimate complaint about git-push? Try: "git-add allows either --all or -A, but git-push only allows --all."