3 ms·

(In addition to "current" already being taken...) If it were called your "intuitive" name ("current", meaning "this is the current default"), then it would, ex

by jlgreco 13y ago

(In addition to "current" already being taken...) If it were called your "intuitive" name ("current", meaning "this is the current default"), then it would, extremely unintuitively, require renaming if it ever stopped being the default. You would be sacrificing future coherence for the sake of some very mild "intuitive sense" during the present. 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.

jeorgun 13y ago
I'm pretty sure "current" in this case is supposed to mean "branch you're currently on", which I'd definitely find more intuitive than "default". On the other hand, apparently that meaning isn't actually as clear as I'd have guessed, so maybe my intuitions about intuitiveness are off-base.
- jlgreco 13y ago
  That is what current means right now. His proposal seems to be "call whatever happens to be the default 'current'". This of course gets you into a non-intuitive "The king is dead, long live the king" sort of situation.
  - hibbelig 13y ago
    I understand that blumentopf meant that "current" should mean "push the current branch", just like "simple" is documented to do. He didn't know that there are actually _two_ behaviors that "push the current branch", and one of them is named "current" whereas the other, new one, is named "simple" ...
  - clhodapp 13y ago
    You are assuming one specific reading, when there are at least two valid ones. The way I read the comment was basically to say, "Geez, what git calls 'simple' ('push the current branch into the remote branch from which you are pulling, but only if they have the same name. This is supposed to be "more safe" for beginners than the "upstream" mode.') sounds like it would be better-named as 'current'. Isn't this obvious to everyone, including the git developers? Why are these unintuitively named options so frequent in git?" That said, I disagree with the sentiment, since there is already a 'current' mode to which the 'current' name seems to apply at least equally well.
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 ago
  push.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."

by jlgreco 13y ago

jeorgun 13y ago

I'm pretty sure "current" in this case is supposed to mean "branch you're currently on", which I'd definitely find more intuitive than "default". On the other hand, apparently that meaning isn't actually as clear as I'd have guessed, so maybe my intuitions about intuitiveness are off-base.

jlgreco 13y ago
That is what current means right now. His proposal seems to be "call whatever happens to be the default 'current'". This of course gets you into a non-intuitive "The king is dead, long live the king" sort of situation.
- hibbelig 13y ago
  I understand that blumentopf meant that "current" should mean "push the current branch", just like "simple" is documented to do. He didn't know that there are actually _two_ behaviors that "push the current branch", and one of them is named "current" whereas the other, new one, is named "simple" ...
- clhodapp 13y ago
  You are assuming one specific reading, when there are at least two valid ones. The way I read the comment was basically to say, "Geez, what git calls 'simple' ('push the current branch into the remote branch from which you are pulling, but only if they have the same name. This is supposed to be "more safe" for beginners than the "upstream" mode.') sounds like it would be better-named as 'current'. Isn't this obvious to everyone, including the git developers? Why are these unintuitively named options so frequent in git?" That said, I disagree with the sentiment, since there is already a 'current' mode to which the 'current' name seems to apply at least equally well.

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 ago
push.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."