Re: [PATCH 2/6] bisect: fix "--" detection when a term name is "--"
- From
Christian Couder <christian.couder@gmail.com>
- Date
- Sep 23, 2026, 08:11 UTC
- Message-ID
- <CAP8UFD3sh9Ejfgv7CB33LRU_z3i662_+tjdW7JqwRrzexWX_Ow@mail.gmail.com>
- In-Reply-To
- <xmqqse3rffr4.fsf@gitster.g>
On Thu, Sep 3, 2026 at 12:30 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 21 quoted lines
> > Christian Couder <christian.couder@gmail.com> writes: > > > `bisect_start()` walks its arguments twice. The second loop actually > > parses the options, and it knows that `--term-good`, `--term-old`, > > `--term-bad` and `--term-new` take their value as a separate argument, > > so it skips that value. > > > > The first loop, which only looks for the "--" separating revisions from > > paths, doesn't know about these options. So when such an option is given > > "--" as its value, that "--" is mistaken for the separator and > > `has_double_dash` is wrongly set. > > It may be theoretically true, but I wonder how much practical value > it has to correctly parse "--term-good --" as "Ah, the user wants to > mark good revisions as '--' instead of 'good' or 'old'"? Even > though "refs/bisect/--" is *not* forbidden, how likely is it for > users to do that? > > This is not like "git grep -e --" which does have much more pracical > value.
Right, this patch and the next one have been removed from v2.
In the future we can still convert bisect_start() to the parse-options API, and then use the early-scan API to look for "--" in a bit cleaner way.