Re: An idea for "git bisect" and a GSoC enquiry

On 27 February 2014 06:47, Christian Couder <christian.couder@gmail.com> wrote:

I have also, at one time, started working on this problem, though I never submitted any of my patches :(. I went the way of renaming the internal logic to make it less tied to the good/bad distinction that is currently hard coded in. That may not be the best starting point, but let me summarise the thoughts I had at the time, particularly around the different adjective pairs that we might use.

A general description of git bisect is that you start with a commit that exhibits a given property, find a commit that does not have that property, and then look for when the property was introduced. I think of this property as the 'bisect property' of the bisect search. The property is described with our adjective pair, currently 'bad' (with the property) and 'good' (without the property). We assume that commits with the property have an ancestor without the property, and as this assumption is so essential to how git bisect works I think of it as the 'bisect relationship' of the bisect search, and we care about the direction of this relationship between commits.

The proposed adjectives tend to be along the lines of the following:

- good->bad (current); good<->bad
The bisect property is currently always described as 'bad', the
introduction of a bug being the motivating use case. The problem with
this is that we often want to find when a 'good' behaviour was
introduced, or when a neutral change occurred.
A solution is to allow reversing our bisect relationship, by either
detecting the intended direction or allowing the user to choose. If we
reverse the direction our adjectives also flip, and so the bisect
property we are now looking for is 'good' instead of 'bad'. The terms
good and bad don't work well with neutral searches.

- unfixed->fixed
For this pair, the bisect property would always be described by the
'fixed' adjective. It seems odd to ever reverse the bisect
relationship, as we don't usually say something was 'fixed' and then
became 'unfixed'. The behaviour of this pair would thus be near
identical to current usage of 'good->bad', but with the bisect
property conceptually reversed (when was a bug fixed vs when was a bug
introduced).

- old->new
This pair avoids making any judgement on what type of bisect property
we have. The adjectives are thus simply describing the bisect
relationship, and the user is free to use any bisect property they
wish. The main problem with this is that it is possible to have
commits without the property (thus described as 'old') that were made
chronologically after a commit with the property ('new'). This has the
potential to cause confusion for users.

- without->with
This pair also avoids making a judgement on the bisect property, but
avoids potential chronological confusion that 'old->new' has. You
could potentially allow users to reverse the bisect relationship's
direction, but these adjectives allow you to easily invert the bisect
property without causing confusion. For example, 'without bug XYZ' can
instead be written as 'with bug XYZ fixed'.

----

My preference is for the without->with adjective pair, as I believe it maps most closely to the concept of finding a commit that changed a given property, and it allows that property to be negated without introducing too much confusion. Reversing the relationship's direction would also make sense, however that is a significantly greater change to the commands logic.

Thus, my initial work was to refactor the internal naming to use the terms with and without, as that would make a better place from which to add other features (such as reversing the relationship direction, or adding new adjective pairs).

Sorry if that is all confusing to read, or if I'm repeating things that have been said before :)

Regards,

Andrew Ardill