Hi, On Saturday 26 March 2011 19:48:25 Jim Cromie wrote: > sometimes its feels clearer to devote a commit to changing (for example) > the definition of a struct; and changing all users of that struct in > the next commit. > This isolates and highlights the definitional change, rather than burying > it in the middle of a huge diff. > > The downside of doing this is that git bisect will trip over this 1/2 > change. It would be nice if a committer could mark the commit as not > bisectable, perhaps by just adding this, on a separate line, to the > commit-message: > > "git bisect skip [optional range]" > > the range presumably would be something like CURRENT^1 > except that it would make more sense to flag successors than ancestors, > and of course, CURRENT would have to mean something. > > Anyway, range isnt really needed, as any subsequent interim commits > could also flag themselves as such. > > git bisect already has ability to skip a commit, this just helps an > automated bisection script. Please look at this recent thread: http://thread.gmane.org/gmane.comp.version-control.git/169026/ where there are other suggestions and discussions about how to deal with this kind of problems. Thanks, Christian. -- 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