3 ms·

> with git checkout you can create and switch to the new branch in one command using the -b flag: git checkout -b new_branch > You can do the same with the new

> with git checkout you can create and switch to the new branch in one command using the -b flag: git checkout -b new_branch > You can do the same with the new one, but the flag is -c: git switch -c new_branch It's like they had a design meeting where they discussed this and said "so I propose switch -b newbranch to create and switch to a new branch" and the objection was "nah that would make it consistent with checkout, which is against the project policy"

ReFruity 5y ago
Well, maybe it indicates specifically that they had no meeting :)
eevilspock 5y ago
The purpose of `git switch` is to switch branches, and its normal argument is a branch ref. Thus -b for "branch" would be redundant and confusing. -c is for "create", i.e. create the branch that i want to switch to. The whole point of adding git switch and git restore is to come up with more user friendly porcelain. Otherwise we might as well stick with git checkout. git checkout is maximally consistent with git checkout!
- alkonaut 5y ago
  How does -b mean “create” in checkout? I get that it means “branch” but why is “branch” what I use to create a new one? The problem here is obviously the choice made for checkout, not switch. But consistency is more important so it’s better to keep consistency than “correctness” here imo. This problem already happened in the past with -d (delete).
  - bendiksolheim 5y ago
    Which is better depends on what you want to achieve. In this case, the whole point is to make git easier to use as a tool. Carrying over ideas we already know are confusing would therefore be wrong in my opinion.
  - eevilspock 5y ago
    Keep in mind this is your opinion. Unless you've done a poll of users (my comment is getting a lot of upvotes), you have no idea what most people prefer. I can come up with more reasons why -c is better, why consistency in this case is not an issue, and why -b makes sense for checkout, but it's not worth the time debating opinions on a done deal. The only reason I bothered commenting is your comment pretty much called them stupid because their decision didn't line up with what you would have done.
    - alkonaut 5y ago
      I don’t have as much issue with this particular switch as I do with the taped together ball of aggregated mud that is the existing set of git commands. Those are the reason I found this particular one amusing. I would have preferrec consistency over intuitive (or allowing both!) but as you say I have no idea what a majority of users would prefer. I’m pretty sure whoever chose this doesn’t either (another problem with relying on software that can’t pay thousands of dollars for UX testing). The fundamental problem with this UX is that it (like so many Unix tools) doesn’t draw a hard line between interactive use and scripting use, so making large changes is out of the question since the interactive UX is already scripted in thousands of aliases and CI scripts. That’s a different topic though.
      - Denvercoder9 5y ago
        > I don’t have as much issue with this particular switch as I do with the taped together ball of aggregated mud that is the existing set of git commands. You're expecting the impossible. The current set of commands isn't great, everyone agrees on that, but they're too engraved in the minds of millions of developers to change. Thus, to solve the problem, the git developers come up with a new set of commands. By definition they won't be consistent with the current set of commands, as they're meant to solve the problems the current set has. You have an issue with the new commands not being compatible, but you also have an issue with the old commands, that the new commands would replicate if they were compatible. What do you actually expect the developers to do?
        5y ago
  - CRConrad 5y ago
    > How does -b mean “create” in checkout? I get that it means “branch” but why is “branch” what I use to create a new one? Because you can "checkout" other stuff too, not just branches. > But consistency is more important so it’s better to keep consistency than “correctness” here imo. Huh? I thought the whole point of these new commands was to try and fix the old illogical command line interface. Since one of the main problems -- probably the main problem -- is precisely the lack of consistency, the new ones logically just cannot be consistent with all the old ones, because then they would be just as inconsistent among themselves as the old ones. Something somewhere has to give. (And IMO this "-b" seems as good a candidate for the chop as any.)
    - alkonaut 5y ago
      Yes - if this is meant to be a whole new set of commands which are internally consistent and can be used without using the others, then it makes sense to do it right. But is that the case? Won’t this just be used in addition to the old commands (except checkout)? The worst case would be adding commands that attempt to fix an UX but which don’t replace it, creating two separate UXes you must use at the same time. Anyone who uses the Windows control panel knows.
      - CRConrad 5y ago
        > But is that the case? Dunno. (Elsewhere in this thread, the guy who built them reported that he isn't on the git dev team any more, so perhaps not too promising.) > Won’t this just be used in addition to the old commands (except checkout)? That's still a massive improvement, since checkout was arguably the main culprit. Also, it was never the case that you'd have to replace all git commands to achieve consistency: Many (hopefully most) already had consistent naming of arguments and options. So make your new ones compatible with the largest set of internally-consistent ones already present, and you only need to replace a minority. (Worst case, if all N were incompatible with each other, you'd have to replace N-1 -- but you could still keep one. :-) Then there's also usage frequency to consider. Given that checkout is the command most inconsistent with others, often inconsistent even with itself, and among the very most used ones overall -- almost certainly, in my estimation, the most used of the candidates for replacement -- I'd say even if nothing more comes of this, it's a huge net win. Also note that it's not a case of "two separate UXes you must use at the same time": git checkout is still there; no piece of the "old control panel" has -- AFAIK, or has any? -- been disabled or removed.
notatoad 5y ago
i think they had a design meeting where they said "lets add some new commands to make git easier for newbies". carrying over flags whose abbreviated forms don't make any sense in the new context doesn't make anything easier for anybody. if you want to keep using the commands you have memorized, you can do that - just don't use switch or restore. the new commands are different, that's the point.
- alkonaut 5y ago
  Probably. But choosing the wrong-but-consistent flag would have been easier to learn and remember. I don’t think anyone will consider different git commands as old/new, or core/porcelain or whatever it is. I just want semantical “delete” to have the same switch name, for example.
  - awestroke 5y ago
    -c is for create. Very easy to remember.
    - patal 5y ago
      Sure. But you gotta see the benefit of a "-b" flag creating a branch in every Git command consistently (where it makes sense). That would be easy to remember!
    - alkonaut 5y ago
      Yes. But when I remember to git checkout -c to “create” it doesn’t help me much.
      - deleted 5y ago
        [deleted]
afiori 5y ago
That is probably what happened, with the observation that being consistent with checkout is a terrible idea for everything, as checkout is a clusterfuck of a command

ReFruity 5y ago

Well, maybe it indicates specifically that they had no meeting :)

eevilspock 5y ago

The purpose of `git switch` is to switch branches, and its normal argument is a branch ref. Thus -b for "branch" would be redundant and confusing. -c is for "create", i.e. create the branch that i want to switch to. The whole point of adding git switch and git restore is to come up with more user friendly porcelain. Otherwise we might as well stick with git checkout. git checkout is maximally consistent with git checkout!

alkonaut 5y ago
How does -b mean “create” in checkout? I get that it means “branch” but why is “branch” what I use to create a new one? The problem here is obviously the choice made for checkout, not switch. But consistency is more important so it’s better to keep consistency than “correctness” here imo. This problem already happened in the past with -d (delete).
- bendiksolheim 5y ago
  Which is better depends on what you want to achieve. In this case, the whole point is to make git easier to use as a tool. Carrying over ideas we already know are confusing would therefore be wrong in my opinion.
- eevilspock 5y ago
  Keep in mind this is your opinion. Unless you've done a poll of users (my comment is getting a lot of upvotes), you have no idea what most people prefer. I can come up with more reasons why -c is better, why consistency in this case is not an issue, and why -b makes sense for checkout, but it's not worth the time debating opinions on a done deal. The only reason I bothered commenting is your comment pretty much called them stupid because their decision didn't line up with what you would have done.
  - alkonaut 5y ago
    I don’t have as much issue with this particular switch as I do with the taped together ball of aggregated mud that is the existing set of git commands. Those are the reason I found this particular one amusing. I would have preferrec consistency over intuitive (or allowing both!) but as you say I have no idea what a majority of users would prefer. I’m pretty sure whoever chose this doesn’t either (another problem with relying on software that can’t pay thousands of dollars for UX testing). The fundamental problem with this UX is that it (like so many Unix tools) doesn’t draw a hard line between interactive use and scripting use, so making large changes is out of the question since the interactive UX is already scripted in thousands of aliases and CI scripts. That’s a different topic though.
    - Denvercoder9 5y ago
      > I don’t have as much issue with this particular switch as I do with the taped together ball of aggregated mud that is the existing set of git commands. You're expecting the impossible. The current set of commands isn't great, everyone agrees on that, but they're too engraved in the minds of millions of developers to change. Thus, to solve the problem, the git developers come up with a new set of commands. By definition they won't be consistent with the current set of commands, as they're meant to solve the problems the current set has. You have an issue with the new commands not being compatible, but you also have an issue with the old commands, that the new commands would replicate if they were compatible. What do you actually expect the developers to do?
      - 5y ago
- CRConrad 5y ago
  > How does -b mean “create” in checkout? I get that it means “branch” but why is “branch” what I use to create a new one? Because you can "checkout" other stuff too, not just branches. > But consistency is more important so it’s better to keep consistency than “correctness” here imo. Huh? I thought the whole point of these new commands was to try and fix the old illogical command line interface. Since one of the main problems -- probably the main problem -- is precisely the lack of consistency, the new ones logically just cannot be consistent with all the old ones, because then they would be just as inconsistent among themselves as the old ones. Something somewhere has to give. (And IMO this "-b" seems as good a candidate for the chop as any.)
  - alkonaut 5y ago
    Yes - if this is meant to be a whole new set of commands which are internally consistent and can be used without using the others, then it makes sense to do it right. But is that the case? Won’t this just be used in addition to the old commands (except checkout)? The worst case would be adding commands that attempt to fix an UX but which don’t replace it, creating two separate UXes you must use at the same time. Anyone who uses the Windows control panel knows.
    - CRConrad 5y ago
      > But is that the case? Dunno. (Elsewhere in this thread, the guy who built them reported that he isn't on the git dev team any more, so perhaps not too promising.) > Won’t this just be used in addition to the old commands (except checkout)? That's still a massive improvement, since checkout was arguably the main culprit. Also, it was never the case that you'd have to replace all git commands to achieve consistency: Many (hopefully most) already had consistent naming of arguments and options. So make your new ones compatible with the largest set of internally-consistent ones already present, and you only need to replace a minority. (Worst case, if all N were incompatible with each other, you'd have to replace N-1 -- but you could still keep one. :-) Then there's also usage frequency to consider. Given that checkout is the command most inconsistent with others, often inconsistent even with itself, and among the very most used ones overall -- almost certainly, in my estimation, the most used of the candidates for replacement -- I'd say even if nothing more comes of this, it's a huge net win. Also note that it's not a case of "two separate UXes you must use at the same time": git checkout is still there; no piece of the "old control panel" has -- AFAIK, or has any? -- been disabled or removed.

notatoad 5y ago

i think they had a design meeting where they said "lets add some new commands to make git easier for newbies". carrying over flags whose abbreviated forms don't make any sense in the new context doesn't make anything easier for anybody. if you want to keep using the commands you have memorized, you can do that - just don't use switch or restore. the new commands are different, that's the point.

alkonaut 5y ago
Probably. But choosing the wrong-but-consistent flag would have been easier to learn and remember. I don’t think anyone will consider different git commands as old/new, or core/porcelain or whatever it is. I just want semantical “delete” to have the same switch name, for example.
- awestroke 5y ago
  -c is for create. Very easy to remember.
  - patal 5y ago
    Sure. But you gotta see the benefit of a "-b" flag creating a branch in every Git command consistently (where it makes sense). That would be easy to remember!
  - alkonaut 5y ago
    Yes. But when I remember to git checkout -c to “create” it doesn’t help me much.
    - deleted 5y ago
      [deleted]

afiori 5y ago

That is probably what happened, with the observation that being consistent with checkout is a terrible idea for everything, as checkout is a clusterfuck of a command