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 <mhagger@xxxxxxxxxxxx> wrote: > Please forgive my typos and brevity; this was typed on a phone. > > Michael > On February 27, 2014 5:16:40 PM CET, Jacopo Notarstefano <jacopo.notarstefano@xxxxxxxxx> wrote: >>On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty >><mhagger@xxxxxxxxxxxx> wrote: >>> 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 warning > > 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 >>"good". >>> >>> 2. If a "good" commit is an ancestor of a "bad" one, then "git >>bisect" >>> should announce "I will now look for the first bad commit". If >>> reversed, then announce "I will now look for the first good commit". >>If >>> neither commit is an ancestor of the other, then explain the >>situation >>> 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 >>go >>> 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 >>output >>> would have to be adjusted, as would the way that a bisect is >>visualized. >>> >>> I can't think of any fundamental problems with a scheme like this, >>and I >>> think it would be easier to use than the unfixed/fixed scheme. But >>that >>> 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 >>useful >>> improvement, and has gone unimplemented for a lamentably long time, >>my >>> 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 > mhagger@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html