3 ms·

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

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
  I completely agree, I’m not asking for a completely new set of consistent tools, but an end result that forms a consistent set possibly together with some old ones. If it’s the case that you can now work in a consistent set and never use checkout then that is a big improvement.

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
I completely agree, I’m not asking for a completely new set of consistent tools, but an end result that forms a consistent set possibly together with some old ones. If it’s the case that you can now work in a consistent set and never use checkout then that is a big improvement.