[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    [BUG] 'git bisect start' fails to detect bad revisions without '--'
From:       Philippe Blain <levraiphilippeblain () gmail ! com>
Date:       2021-06-30 18:47:15
Message-ID: 0df90d98-3b79-3751-8712-69e1d44a32fd () gmail ! com
[Download RAW message or body]

Hello all,

I've found a small bug in the argument parsing of 'git bisect 'start',
i.e builtin/bisect--helper.c::bisect_start.

If one mistypes bad (or good) revisions but does not write the double-dash,
the code does not check that the revisions exist and it goes on and checks out HEAD.
 From what I understand the mistyped revisions are (in some cases) interpreted as paths
(they are written to '.git/BISECT_NAMES), even if they do not match any paths...

For example, these invocations all check out HEAD and do not give any error in git.git:

	git bisect start BAD GOOD
	git bisect start v2.31.0 GOOD
	git bisect start v2.31.0 GOOD ANOTHER

But these correctly error:

	git bisect start BAD GOOD --
	git bisect start v2.31.0 GOOD --
	git bisect start v2.31.0 GOOD ANOTHER --
	git bisect start v2.31.0 v2.30.0 GOOD BAD

This one does not error and correctly checks out the mid point between 2.31 and 2.30,
but does not check that BAD exists (in this case it's not written to BISECT_NAMES):

	git bisect start v2.31.0 v2.30.0 BAD


This is on the latest master, 670b81a890 (The second batch, 2021-06-14). I tried older versions
before the start of the conversion of 'git bisect' from shell to C and they seem to behave the same.

I'm CC-ing Christian and Dscho since I noticed 73c6de06af (bisect: don't use invalid oid
as rev when starting, 2020-09-25) touched the argument parsing in 'bisect start' and is tangentially
related.

Cheers,

Philippe.
[prev in list] [next in list] [prev in thread] [next in thread]