[administrivia: added people involved in the main discussion thread back
on CC line, and also added CCouder who seems to be fond of the command]
Michal Vyskocil [off-list ref] writes:
The bugfix command works like the previous git bisect start --reverse.
Does any released version of git have "bisect start --reverse"?
$ git bisect start --reverse
unrecognised option: '--reverse'
Let's suppose that we had a "git frotz" Porcelain subcommand, that used to
say "xyzzy" when all is well, but says "nitfol" these days. I released a
(bad) script that parses the output from the subcommand, and want to say
something like "This script only works with Git version after X", and to
find out the value of X, I need to bisect the history to find when "frotz"
started to say "nitfol".
I am not trying to find a commit that introduced a bug/regression to cause
the recent "frotz" to say "nitfol". Neither am I trying to find a fix that
corrected the earlier bogus output "xyzzy". No value judgement is involved
in this scenario.
I wonder if something along the following line would make the usage more
pleasant and self-explanatory:
$ git bisect start --used-to='git frotz says xyzzy' v0.99 master
Bisecting: 171 revisions left to test after this (roughly 8 steps)
$ ... build and then test ...
$ git bisect tested
You are trying to check: git frotz says xyzzy
Does the result satisify what you are trying to find [y/n]? yes
Saying 'yes' would be like saying 'good' and 'no' would be like saying
'bad' here.
When trying to find regression, you would say:
$ git bisect start --used-to='it works' v0.99 master
and you say 'yes' if it works (equivalent to 'good'), and 'no' if it does
not (equivalent to 'bad').
When trying to find a fix, you would say:
$ git bisect start --used-to='checkout $tree $path clobbers $path' v0.99 master
and you say 'yes' if it is still broken at the tested version (equivalent
to your reversed 'good'), and 'no' if the tested version contains a fix
(equivalent to your reversed 'bad').
I am not married to the name of the option, but --used-to='...' felt more
or less self-explanatory name to signal users what to describe in that
text. The condition "You are trying to check:" cue wants to remind the
user is "we used to do *this* but now we don't", and the command is trying
to see when it changed.
Thoughts?
On Fri, Sep 30, 2011 at 11:13:25AM -0700, Junio C Hamano wrote:
I wonder if something along the following line would make the usage more
pleasant and self-explanatory:
$ git bisect start --used-to='git frotz says xyzzy' v0.99 master
Bisecting: 171 revisions left to test after this (roughly 8 steps)
$ ... build and then test ...
$ git bisect tested
You are trying to check: git frotz says xyzzy
Does the result satisify what you are trying to find [y/n]? yes
I like this idea a lot. My "yes/no" thing was a "if I were designing
bisect from scratch today..." suggestion, but having something like
--used-to makes it a natural addition to the regular good/bad interface.
And I really like the prompt to help people remember what it is they're
declaring each time.
However, --used-to feels a bit backwards to me. I think of it as
"--has-property" or something similar. That is, you are looking for when
something appeared (be it a bug, a feature, or whatever). But I guess it
depends on what you are bisecting. In my case, "yes" would be the
current "bad", and "no" would be the current "good".
So maybe provide both --used-to and --has-property (which I really
dislike as a name, but I can't think of anything better at the moment).
And then we can interpret "yes" and "no" accordingly, depending which
one the user used (and while that _sounds_ confusing, it won't be to the
user; we'll be prompting them with "you're looking for ...", so their
answer will be very natural).
But with both of them, the user is free to phrase it in whatever way
feels natural.
When trying to find regression, you would say:
$ git bisect start --used-to='it works' v0.99 master
Just for completeness, under my proposal this could also be:
$ git bisect start --has-property='git frotz is broken' v0.99 master
Which is probably slightly less natural. But:
When trying to find a fix, you would say:
$ git bisect start --used-to='checkout $tree $path clobbers $path' v0.99 master
This one would be a bit nicer:
$ git bisect start --has-property='checkout works' v0.99 master
-Peff
PS Side note: do we really need it to be interactive? I would think
you could do:
$ git bisect start --used-to='git frotz says xyzzy'
Bisecting: 171 revisions left to test after this (roughly 8 steps)
Checking whether 'git frotz says xyzzy'.
$ ... build and test ...
$ git bisect yes
Bisecting: 89 revisions left to test after this (roughly 7 steps)
Checking whether 'git frotz says xyzzy'.
It means the user is reminded, then tests, then responds. But I think
it would be enough of a reminder. The important thing is that we keep
mentioning it at each bisection step. Maybe it depends on how long
your build/test step is (I tend to work on things like git, where
that is a 30-second procedure, not a kernel with a long build and a
reboot in between :) ).