Re: [PATCH 2/4] switch: allow to switch in the middle of bisect

From: Duy Nguyen <pclouds@gmail.com>
Date: Jun 20, 2019, 15:06 UTC
Message-ID: <CACsJy8DoEwoR67BopXLPiBmuidixREn-Ac16V5di6sFZx_Gbng@mail.gmail.com>
In-Reply-To: <446ace86-714f-9109-99d8-95554ceaf26b@gmail.com>

On Thu, Jun 20, 2019 at 9:02 PM Derrick Stolee <stolee@gmail.com> wrote:

Show 18 quoted lines

>
> 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.

Until you run "git bisect bad" or "git bisect good" I don't think switching could mess up bisect. And I'm pretty sure I marked wrong ones once or twice and git-bisect did complain.

It would be a good idea to warn about jumping in known-good-or-bad commit ranges. I'll keep this as an improvement point (there's still another one I haven't done, also about warning improvement, sigh).

Show 11 quoted lines

> > 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 -".

I actually wanted to go a bit more aggressive/verbose about "teaching" users via the advice framework, but allows the user to turn off the "lessons" they already learned. Something like gcc adding [-Wno-foobar] in a warning to hint how to turn it off. I'll come back to this at some point, hopefully.

-- 
Duy