On Tue, Mar 12, 2019 at 12:25 AM Elijah Newren <newren@xxxxxxxxx> wrote: > > On Mon, Mar 11, 2019 at 4:47 AM Duy Nguyen <pclouds@xxxxxxxxx> wrote: > > > > 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. > > No objection here; I like this idea. One last thing. What about --detach? Should it have the same protection or should we let the user doing --detach (experiments) take the responsibity to not screw themselves up? -- Duy
