5 ms·

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

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?
      - alkonaut 5y ago
        > You don't find it interesting you are armchair quarterbacking 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
- CRConrad 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 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.

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?
    - alkonaut 5y ago
      > You don't find it interesting you are armchair quarterbacking 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
CRConrad 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 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.