This email was sent privately by Michael to me as a result of my
previous error. I'm quoting it in its entirety so that he doesn't have
to submit it twice.
On Thu, Feb 27, 2014 at 8:32 PM, Michael Haggerty <mhag...@alum.mit.edu> wrote:
> Please forgive my typos and brevity; this was typed on a phone.
> On February 27, 2014 5:16:40 PM CET, Jacopo Notarstefano
> <jacopo.notarstef...@gmail.com> wrote:
>>On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty
>>> What happens if the user mixes, say, "good" and "fixed" in a single
>>> bisect session?
>>I don't think that's an issue. If the user uses the label "fixed"
>>instead of "bad" she will have a hard time remembering to use it every
>>time she needs it, and maybe the output of "git bisect" will look very
>>confusing, but what can git do? This is a semantic user input error,
>>not a syntax one.
> - git could emit an error message and refuse to continue
> - git could interpret the command one way or the other, with or without a
> By my count that gives at least five possibilities. The feature cannot be
> implemented without choosing one.
>>> I think it would be more convenient if "git bisect" would autodetect
>>> whether the history went from "good" to "bad" or vice versa. The
>>> algorithm could be:
>>> 1. Wait until the user has marked one commit "bad" and one commit
>>> 2. If a "good" commit is an ancestor of a "bad" one, then "git
>>> should announce "I will now look for the first bad commit". If
>>> reversed, then announce "I will now look for the first good commit".
>>> neither commit is an ancestor of the other, then explain the
>>> and ask the user to run "git bisect find-first-bad" or "git bisect
>>> find-first-good" or to mark another commit "bad" or "good".
>>> 3. If the user marks another commit, go back to step 2, also doing a
>>> consistency check to make sure that all of the ancestry relationships
>>> in a consistent direction.
>>> 4. After the direction is clear, the old bisect algorithm can be used
>>> (though taking account of the direction). Obviously a lot of the
>>> would have to be adjusted, as would the way that a bisect is
>>> I can't think of any fundamental problems with a scheme like this,
>>> think it would be easier to use than the unfixed/fixed scheme. But
>>> is only my opinion; other opinions are undoubtedly available :-)
>>I like this idea! It also looks fun to implement. A minor difference
>>is that I'd rather die with an error on point 2) if there's no
>>ancestorship relation between the two commits; if the user is asking
>>for such a thing then she has a fundamental misconception of the state
>>of her repository.
> That is not correct. If there is a bug on one branch but not another, it is
> legitimate to ask when the bug was introduced, and git bisect can indeed
> handle this case today (think about how this could work, and try it!)
>>> By the way, although "git bisect fixed/unfixed" would be a very
>>> improvement, and has gone unimplemented for a lamentably long time,
>>> personal feeling is that it has too meat in it to constitute a GSoC
>>> project by itself.
>>Oh! Then in fact, as Christian Couder said, this project shouldn't be
>>marked as "easy".
> Sorry for the typo; I meant to say "too LITTLE meat".
> Michael Haggerty
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html