On Tue, Nov 20 2018, Duy Nguyen wrote: > On Mon, Nov 19, 2018 at 04:19:53PM +0100, Duy Nguyen wrote: >> I promise to come back with something better (at least it still >> sounds better in my mind). If that idea does not work out, we can >> come back and see if we can improve this. > > So this is it. The patch isn't pretty, mostly as a proof of > concept. Just look at the three functions at the bottom of checkout.c, > which is the main thing. > > This patch tries to split "git checkout" command in two new ones: > > - git switch-branch is all about switching branches Isn't this going to also take the other ref arguments 'git checkout' takes now? I.e. tags, detached HEADs etc? I'm reminded of the discussion about what "range-diff" should be called :) > - git restore-paths (maybe restore-file is better) for checking out > paths If it takes globs/dirs then a plural is probably better. > The main idea is these two commands will co-exist with the good old > 'git checkout', which will NOT be deprecated. Old timers will still > use "git checkout". But new people should be introduced to the new two > instead. And the new ones are just as capable as "git checkout". > > Since the three commands will co-exist (with duplicate functionality), > maintenance cost must be kept to minimum. The way I did this is simply > split the command line options into three pieces: common, > switch-branch and checkout-paths. "git checkout" has all three, the > other two have common and another piece. > > With this, a new option added to git checkout will be automatically > available in either switch-branch or checkout-paths. Bug fixes apply > to all relevant commands. > > Later on, we could start to add a bit more stuff in, e.g. some form of > disambiguation is no longer needed when running as switch-branch, or > restore-paths. > > So, what do you think? That "git checkout" does too many things is something that keeps coming up in online discussions about Git's UI. Two things: a) It would really help to have some comparison of cases where these split commands are much clearer or less ambiguous than git-checkout. I can think of some (e.g. branch with the same name as a file) but having some overall picture of what the new UI looks like with solved / not solved cases would be nice. Also a comparison with other SCMs people find less confusing (svn, hg, bzr, ...) b) I think we really need to have some end-game where we'd actually switch away from "checkout" (which we could still auto-route to new commands in perpetuity, but print a warning or error). Otherwise we'll just end up with https://xkcd.com/927/ and more UI confusion for all.
