On 02/15/2016 06:05 AM, Junio C Hamano wrote: > As to bisect pathspec, while I do not think it is sensible to change > it in the middle of bisection, I do not think it would cause the > bisect command to produce an incorrect result if you did so. You > would be changing the definition of what is the "middle point" of > the history on the fly by changing the pathspec, hence you may end > up making the bisection suboptimal, but it shouldn't affect the > correctness of the bisection. Yep I also think it would not affect the correctness. To reformulate your explanation: changing the pathspec does not change the good and bad "frontiers". And those should be still correct under the assumption you're still looking for the same bug/regression. As to the question if it is sensible, I also don't really think it could be helpful. The only way I would expect it to be useful, it so "refine" the search by adding specific files to the filepath. But then it's possible to end up in a dead-end if the commits left are not touching the specified files with: No testable commit found. Maybe you started with bad path parameters? I have also seen other messed up messages, like "-1 commits left" while playing around. > So I tend to agree with you that it is a good idea to be prepared to > parse what the end user may have futzed with the editor, as long as > the user did not break the syntax of the quoted string. Now I am not convinced anymore, because I think if it potentially leads to troubles, it should not be made easier to get oneself into them. > Side note: of course, you can instead say "while it is > technically possible, we have never advertised this file to > be editable by user, or encouraged them to do so" and > tighten the parsing to assume only what we write out, > erroring out when we see any attempt to edit it. I will include something like that in the patch v2 that is to follow soon. -- 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