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!
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.
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.
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?
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.
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?
This is hacker news. It’s basically a few thousand armchairs. Welcome.
> You assume there is no design process.
I’m not saying that. I was just a few minutes ago explaining how I have tried to see traces of it. From the software itself there aren’t any obvious signs of (long term) UX design.
> the most successful VCS software in existence
Lots of stuff is wildly successful despite being an aggregated ball of mud (php, js, unix, c++…). Good (intuitive, consistent) UX is in no way required for popularity or success.
> 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?
The fact that none of them are popular I think is due to the problem with such extensions, that soon enough you have to write something portable (a CI script for example) that runs on vanilla git.
> Or is your beef with all of programmerdom, for choosing git as the platform for open source dev?
I like git, and I hate git. Git is simultaneusky hideous and awesome. I really really hope git isn’t the end of VCS, even though it’s now one of the better ones.
> your language has been more judgmental than concern
Fair point. I do enjoy pissing on things that look or feel Unix-y
Uh... Git was created by the guy who created Linux.
Initially to help manage distributed Linux dev. Not forced on anyone other than Linux devs. Not dominant through nefarious business practices like MS Windows, but because it spread *organically* overtaking other "well designed" systems. People voted with their feet.
Seems unreasonable:
* The problem with the "taped together ball of aggregated mud" is that commands and switches are illogical and inconsistent.
* These new commands are an attempt to fix that by introducing a set of (AIUI) parallel commands with better internal consistency.
* And now your complaint is that the new ones aren't consistent with the old ones?
No, of fucking course they aren't consistent with the old inconsistent ones. That's the whole point: If they were consistent with the inconsistent ones, they would also be inconsistent.
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.)
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.
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.