3 ms·
Speculation: git's _U_X is considered terrible, because it was not built to be used by _U_sers in the first place? It started as an opinionated tool for an opin
by jeffreygoesto 4y ago
Speculation: git's _U_X is considered terrible, because it was not built to be used by _U_sers in the first place? It started as an opinionated tool for an opinionated workflow done by a small number of peers?
- vba616 4y ago>an opinionated tool for an opinionated workflow done by a small number of peers This is a less than clear way of saying its purpose is gatekeeping, discouraging the "wrong sort of people". I'm not saying that gatekeeping is always wrong, or that even when it's wrong that it's worth fighting to change a culture rather than going off and doing your own thing. But I do think it's worth consciously considering whether the particular culture of Linux kernel development has to transfer to all other software projects.
- jeffreygoesto 4y agoI did not want to imply that. Rather that it was a tool for a small number of people with a certain mindset, that was never adapted as adoption grew.
- vba616 4y agoI thought that you were repeating or paraphrasing a widespread description originating with Linus so I wasn't really speaking to your intentions.
- somat 4y agoGit's ui is bad because it was not planned out. people added features as they needed them without enough gatekeeping to maintain consistency. Linux in general is notorious for it's bad interfaces(I'm looking at you iptables) I regard fossil as the gold standard of a good version control command line interface. but it has the benefit of having effectively one developer. but even hg has a more consistent interface. did they just care more? perhaps it was the benefit of learning from the mistakes of git?
- Someone 4y ago> even hg has a more consistent interface. did they just care more? perhaps it was the benefit of learning from the mistakes of git? If they learned from the mistakes of git, they must have learned fast. According to Wikipedia, the first release of mercurial was on April 19, 2005 (https://en.wikipedia.org/wiki/Mercurial https://en.wikipedia.org/wiki/Mercurial), just 12 days after the first release of git on April 7, 2005 (https://en.wikipedia.org/wiki/Git https://en.wikipedia.org/wiki/Git) Or did they do what git should have done: early on bite the bullet for a complete overhaul of the CLI, making the various options consistent?