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. > > Michael > 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 >><mhag...@alum.mit.edu> 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 > mhag...@alum.mit.edu -- 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
