4 ms·

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 "cr

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?
      - alkonaut 5y ago
        I think the idea of a new set is great, but then I think it needs to have a bigger scope than this pair of commands. Perhaps a whole new suite that is consistent and can replace most if not all typical tasks. If this pair of commands is part of a larger suite of porcelain that is internally consistent that’s great. Or at least part of a design or plan for such a “new toolset” where more commands will follow - that’s also a good solution. The important bit is the design process and long term plans so it isn’t just more slow aggregating which was how git got into the current state in the first place. If there is more to this retooling project than meets the eye (in this article) then great. My fear is that it’s more inconsistent aggregation, again - but it’s not obviously the case of course.
        eevilspock 5y ago
        You don't find it interesting you are armchair quarterbacking the most successful VCS software in existence, disregarding that it evolved, that its API reflects that? You assume there is no design process. You're making a lot of assumptions and simplifications. Concern or worry even "fear" are fine, but your language has been more judgmental than concern. There are plenty of git wrappers that offer a cleaner API; you are totally free to use any of those, write your own, or to ditch Git altogether. Or is your beef with all of programmerdom, for choosing git as the platform for open source dev?
- 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.

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?
    - alkonaut 5y ago
      I think the idea of a new set is great, but then I think it needs to have a bigger scope than this pair of commands. Perhaps a whole new suite that is consistent and can replace most if not all typical tasks. If this pair of commands is part of a larger suite of porcelain that is internally consistent that’s great. Or at least part of a design or plan for such a “new toolset” where more commands will follow - that’s also a good solution. The important bit is the design process and long term plans so it isn’t just more slow aggregating which was how git got into the current state in the first place. If there is more to this retooling project than meets the eye (in this article) then great. My fear is that it’s more inconsistent aggregation, again - but it’s not obviously the case of course.
      - eevilspock 5y ago
        You don't find it interesting you are armchair quarterbacking the most successful VCS software in existence, disregarding that it evolved, that its API reflects that? You assume there is no design process. You're making a lot of assumptions and simplifications. Concern or worry even "fear" are fine, but your language has been more judgmental than concern. There are plenty of git wrappers that offer a cleaner API; you are totally free to use any of those, write your own, or to ditch Git altogether. Or is your beef with all of programmerdom, for choosing git as the platform for open source dev?
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.