author | Linus Torvalds <torvalds@ppc970.osdl.org> | |
Sat, 18 Jun 2005 05:54:50 +0000 (22:54 -0700) | ||
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | |
Sat, 18 Jun 2005 05:54:50 +0000 (22:54 -0700) | ||
commit | 8b3a1e056f2107deedfdada86046971c9ad7bb87 | |
tree | 6414aac945a94018a479560bc4a7894826cab95a | tree | snapshot |
parent | 753fd78458b6d7d0e65ce0ebe7b62e1bc55f3992 | commit | diff |
git-rev-list: add "--bisect" flag to find the "halfway" point
This is useful for doing binary searching for problems. You start with
a known good and known bad point, and you then test the "halfway" point
in between:
git-rev-list --bisect bad ^good
and you test that. If that one tests good, you now still have a known
bad case, but two known good points, and you can bisect again:
git-rev-list --bisect bad ^good1 ^good2
and test that point. If that point is bad, you now use that as your
known-bad starting point:
git-rev-list --bisect newbad ^good1 ^good2
and basically at every iteration you shrink your list of commits by
half: you're binary searching for the point where the troubles started,
even though there isn't a nice linear ordering.
This is useful for doing binary searching for problems. You start with
a known good and known bad point, and you then test the "halfway" point
in between:
git-rev-list --bisect bad ^good
and you test that. If that one tests good, you now still have a known
bad case, but two known good points, and you can bisect again:
git-rev-list --bisect bad ^good1 ^good2
and test that point. If that point is bad, you now use that as your
known-bad starting point:
git-rev-list --bisect newbad ^good1 ^good2
and basically at every iteration you shrink your list of commits by
half: you're binary searching for the point where the troubles started,
even though there isn't a nice linear ordering.
rev-list.c | diff | blob | history |