Hi, I have an idea about handling commits that do not compile at all in git-bisect. For example: git bisect start git bisect bad v2.6.23-rc1 # bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1 git bisect good v2.6.22 # good: [098fd16f00005f665d3baa7e682d8cb3d7c0fe6f] Linux 2.6.22 Then 1f1c2881f673671539b25686df463518d69c4649 will be the next commit git bisect hands out. Now let's assume this commit would not compile. What would the user do? git-bisect good or git-bisect bad? Assume a commit previous to 1f..49 caused an oops (but the user does not know yet), and the user said 'good' on 1f..49 because he did not know what to say (since it did not compile). Then bisect would go the wrong way, marking all left to 1f..49 as good. Ideally, there should be like "git bisect dunno-try-left" and "git bisect dunno-try-right", which allow the user to skip checking 1f..49 and instead try the next commit left or right of 1f..49 (to either go to a commit before the compile failure, or after it). [ What's `git-bisect next` for? ] Jan -- - 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
