It's not really too late for git, if there is sufficient energy around rolling back the change. The relatively standard process for API changes of (1) adding a

It's not really too late for git, if there is sufficient energy around rolling back the change. The relatively standard process for API changes of (1) adding a new command that does the same thing for a major version, (2) adding a deprecation warning and description of the new way to do it (say 'Please use checkout-tree instead') for another major version or two before (3) it stops working in major version 3. That allows people to get used to a syntax change without breaking scripts for a while. The git project has already used that process for other API changes. In fact, it's pretty common practice to do that sort of thing when a given CLI option starts getting too baroque and complex.