On Tue, 24 Jul 2007 15:21:19 +0200 (CEST) Jan Engelhardt <jengelh@xxxxxxxxxxxxxxx> wrote: Hi Jan, > 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? Check out the section "Avoiding to test a commit" in the git-bisect man page; it addresses this issue. Basically you just use git-reset to pick a different nearby commit to compile, and then continue with git bisect good/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). > Sean - 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
