{"thread":{"id":"26748","subject":"Re: [PATCH] Document 'git bisect fix'.","startedAt":"2011-03-16T13:34:02Z","lastAt":"2011-03-16T13:34:02Z","messageCount":1,"participants":["Yann Dirson"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"163470","messageId":"20110316143402.69e66f16@chalon.bertin.fr","threadId":"26748","inReplyTo":null,"subject":"Re: [PATCH] Document 'git bisect fix'.","fromName":"Yann Dirson","fromEmail":"dirson@bertin.fr","sentAt":"2011-03-16T13:34:02Z","receivedAt":"2011-03-16T13:34:02Z","isPatch":true,"sender":{"key":"dirson@bertin.fr","avatar":null},"body":">I'd say the replace method is perfect for transporting an existing fix\n>\"back in time\" when the range of non-bisectable commits is limited. But\n>since you have to replace the right (most recent) commit in that range\n>it is less convenient when you have a fix due to a changed/exotic build\n>environment or such which you do not want in your mainline.\n>\n>Also, you have to rebase the whole history back to the commit which\n>introduced the problem\n\nRight, and that makes it much more difficult when you want to be\nselective about which fixes you want to apply.\n\n-- \nYann Dirson - Bertin Technologies\n"}]}