On 6/20/2019 5:55 AM, Nguyễn Thái Ngọc Duy wrote: > In c45f0f525d (switch: reject if some operation is in progress, > 2019-03-29), a check is added to prevent switching when some operation > is in progress. The reason is it's often not safe to do so. > > This is true for merge, am, rebase, cherry-pick and revert, but not so > much for bisect because bisecting is basically jumping/switching between > a bunch of commits to pin point the first bad one. git-bisect suggests > the next commit to test, but it's not wrong for the user to test a > different commit because git-bisect cannot have the knowledge to know > better. When a user switches commits during a bisect, it can just create new known-good or known-bad commits, right? It won't mess up the next selection of a test commit? I'm imagining someone jumping to a commit between two known-bad commits or something, when it is more likely that they are jumping to a parallel history. > For this reason, allow to switch when bisecting (*). I considered if we > should still prevent switching by default and allow it with > --ignore-in-progress. But I don't think the prevention really adds > anything much. > > If the user switches away by mistake, since we print the previous HEAD > value, even if they don't know about the "-" shortcut, switching back is > still possible. I tell everyone I know about the "-" shortcut, and I'm always surprised they didn't already know about "cd -". > The warning will be printed on every switch while bisect is still > ongoing, not the first time you switch away from bisect's suggested > commit, so it could become a bit annoying. I think a one-line warning is fine, as a power user doing this a lot will develop blinders that ignore the message as they switch during a bisect. -Stolee
