Le mardi 4 novembre 2008, Christian Couder a écrit : > This subcommand should be used when you have a branch or a part of a > branch that isn't easily bisectable because of a bug that has been > fixed latter. > > We suppose that a bug as been introduced at some point, say A, and > that it has been fixed latter at another point, say B, but that > between these points the code is not easily testable because of the > bug, so it's not easy to bisect between these points. > > In this case you can create a branch starting at the parent of A, say > O, that has a fixed history. In this fixed history for example, there > could be first a commit C that is the result of squashing A and B > together and then all the commits between A and B that have been > cherry picked. > > For example, let's say the commits between A and B are X1, X2, ... Xn > and they have been cherry picked after C as Y1, Y2, ... Yn: > > C--Y1--Y2--...--Yn > / > ...--O--A--X1--X2--...--Xn--B--... > > By design, the last cherry picked commit (Yn) should point to the same > tree as commit B. > > So in this case you can say: > > $ git bisect replace B Yn > > and commit B will be tagged with a special name like: > "bisect-replace-with-Yn" > > (A branch that points to commit Yn will also be created with a name > like: "bisect-replace-B") It occured to me that perhaps only the branch is needed and we can get rid of the tag. This should remove the need to check that the branch still exists when we are creating grafts. I will see what I an come up with. Regards, 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
