On 12/03/2019 17:05, Elijah Newren wrote: > On Tue, Mar 12, 2019 at 4:58 AM Duy Nguyen <pclouds@xxxxxxxxx> wrote: >> 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: > >>>>> 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? > > My intuition here is a bit weaker; it would be nice to hear others' > opinions. My best guess thinking it over a bit is that while someone > doing --detach is more likely to know what they are doing than other > users of the 'switch' command, they may also be the kind of person who > is more likely to run interactive rebases and thus had more > opportunities to forget that they are still in the middle of one. I > think I've been guilty of that a few times. So, while this would be > less critical for this case, I lean towards saying that it may still > be helpful anyway, and if nothing else the consistency of handling all > switching cases the same seems beneficial. > I think that having all the switching cases consistent makes sense as it is easy to understand and avoids complications if we end up adding a config option to allow an implicit --detach in the future as suggested in one of the later patches. Best Wishes Phillip
