On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: > > > Hi Duy > > On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote: > > "git checkout" doing too many things is a source of confusion for many > > users (and it even bites old timers sometimes). To remedy that, the > > command will be split into two new ones: switch and > > something-to-checkout-paths. > > I think this is a good idea, thanks for working on it. I wonder if it > would be a good idea to have the new command refuse to checkout a new > branch if there is a cherry-pick/revert/merge/rebase in progress (with > an option to override the check) as switching branches in the middle of > one of those is likely to be confusing to users (if I do it it is > normally because I've forgotten that I've not run 'git whatever > --continue'). Interesting. I think this would be a good default if we have an escape hatch (which could even come later). I often wander off to some other branch and go back. But then half the time I end up forgetting I'm in a middle of something and just "git rebase --quit" :P Of course with git-stash (*) and git-worktree, I guess there's little reason to just switch away from a something-in-progress worktree. I'll try to implement this in the next round, unless someone objects. (*) I hope git-stash remembers and restores "something-in-progress" status. Dunno. Never used it much. > > +-C <new-branch>:: > > +--force-create <new-branch>:: > > + Similar to `--create` except that if `<new-branch>` already > > + exists, it will be reset to `<start-point>`. This is a > > + convenient shortcut for: > > If we're renaming the options to be more meaningful then maybe we should > consider a different name for this one - it has nothing to do with > creating a branch. Maybe --reset or --update? -C can also create a new branch like -c though. --reset or --update does not convey that (and --update sounds a bit too safe). Another option is --recreate. > > +-f:: > > +--force:: > > + Proceed even if the index or the working tree differs from > > + HEAD. Both the index and working tree are restored to match > > + the switching target. This is used to throw away local > > + changes. > > I'd always thought that --force meant "throw away my local changes if > they conflict with the new branch" not "throw them away regardless" > (which is better as it is deterministic). Maybe we can come up with a > clearer name here --discard-changes? At the moment --force does not > throw away conflicts properly (see the script below in my comments about > --merge). Yeah if you want to redefine --force, now is a very good time. Personally I'd rather have separate options than the "one catch all" --force (or worse, multiple of --force). I'll leave this for the community to decide. Adding Elijah too. He also had some concern about "git restore --force". Maybe he's interested in this as well. -- Duy
