(Ok, removed the kernel people, since this is just about the git part...)

On Fri, 2 Mar 2007, Ingo Molnar wrote:
quoted text
> 
> but the conclusion is clear: if multiple bugs are present in the search 
> area then it gets quite difficult to sort it out via git-bisect - but 
> it's not impossible either. The following git-bisect enhancement could 
> have made things easier for me:
> 
>    git-bisect mark-must-have <tree>

It's not quite that easy.

In _your_ case, you always just wanted to try to apply a particular patch 
if it applied cleanly.

But in other cases, what you really want is:

 - *if* commit X is included, apply patch Y

because quite often you might have a "fix" that applies quite cleanly, but 
is totally the wrong thing to do unless the code that actually _needs_ the 
fix is already merged.

It's just that in this case, if the bug didn't exist, the fix wouldn't 
apply either, so it just didn't matter..

Also, even if we had something that git did automatically after it 
selected a commit to bisect on, it still wouldn't really be enough: we'd 
need to 

 (a) handle the failure case cleanly (again, in your case it didn't 
     matter, because it either applied cleanly or wasn't needed at all)

 (b) also handle the case where the user chooses a different point to try 
     because the automatic bisection picked a commit that was untestable. 
     Right now people do that by using "git reset --hard XYZ"

 (c) It's quite possible that the fix to be applied isn't a git commit at 
     all. Again, in your case there happened to be one well-defined commit 
     that did nothing but fix the known bug, but you could easily have had 
     a situation where - if the bug wasn't as obvious, for example - you 
     had a fix being done over _multiple_ commits, or the other way, the 
     fix you actually want to merge is just a part of a commit that does a 
     lot of other things too (that may not be appropriate at other places, 
     and you know will just cause merge errors)

The (b) case could be supplied by having a "git bisect try <XYZ>" 
subcommand instead of having people use "git reset --hard". That might be 
a good thing to do anyway, since it can also do added sanity testing (ie 
testing that the commit to try actually is *inside* the current bisection 
set, because otherwise the bisection simply won't work).

			Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html