Elijah Newren <newren@xxxxxxxxx> writes: > On Tue, Mar 26, 2019 at 8:24 AM Duy Nguyen <pclouds@xxxxxxxxx> wrote: >> On Tue, Mar 26, 2019 at 10:01 PM Elijah Newren <newren@xxxxxxxxx> wrote: > >> Yeah.. --ignore-in-process does not necessarily mean aborting >> something when you just want to get out to examine some other commit. >> And I agree doing nothing seems like the best (or least >> confusing/surprising) option. > ... > Yes, and in the middle of a cherry-pick with a range you've added some > commits to one branch and some to another. In the middle of a revert > you're doing similar. It sounds like crazytown to me (and maybe we > shouldn't provide the --ignore-in-process flag unless users clamor for > it ... It really sounds like --ignore-in-process that _leaves_ the state files around which are known to be unrelated to the new commit pointed out by HEAD is asking for trouble. We just should tell the users "if you want to go examine something else during an in-progress operation, do it elsewhere, or cancel the in-progress operation with 'cmd --abort' (or perhaps 'reset --hard') which will allow 'switch' to move away". The thing is, "switch temporarily to another commit, do some sightseeing and then switch back to the original commit--we did not touch the in-progress state files while doing so, so we ought to come back to exactly the same state to be able to continue" is brittle. Temporarily switching to another commit or branch would need to touch the index (in some irrevocable way) and with future versions of Git, underlying machineries (like UNDO data) other than the index as well. What the user would do after (temporarily) switching out of the in-process state (e.g. controlled by the sequencer) may be destructive (e.g. "switch away temporarily, forget that you've switched away and try to run cherry-pick or rebase").
