Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| git_bisect [2019/02/26 21:37] – [Bisection while ignoring feature branches] rpjday | git_bisect [2019/02/26 21:54] (current) – [Bisection while ignoring feature branches] rpjday | ||
|---|---|---|---|
| Line 232: | Line 232: | ||
| If we have two commits directly on the '' | If we have two commits directly on the '' | ||
| - | Rather than bisecting completely on those lengthy feature branches, we can restrict the search to just those commits where feature branches were merged into '' | + | Rather than bisecting completely on those lengthy feature branches, we can restrict the search to just those commits where feature branches were merged into '' |
| - | + | ||
| - | Let's demonstrate this using the Linux kernel source repository, defining '' | + | |
| First, let's count the number of commits we would normally need to process if we used basic bisection based on those two endpoints: | First, let's count the number of commits we would normally need to process if we used basic bisection based on those two endpoints: | ||
| Line 244: | Line 242: | ||
| </ | </ | ||
| - | That's a lot of commits so let's see if we can reduce that number. | + | That's a lot of commits so let's see if we can reduce that number. The basis for ignoring all of the commits on feature branches is to generate a list of commits to //ignore//, and feed that list to '' |
| - | + | ||
| - | The basis for ignoring all of the commits on feature branches is to generate a list of commits to //ignore//, and feed that list to '' | + | |
| < | < | ||
| Line 254: | Line 250: | ||
| </ | </ | ||
| - | So there are 1161 merge commits in the testable range, but we need to further disqualify merge commits on feature branches, so let's restrict ourselves to just the first parents of those merge commits, which guarantees that all of those merge commits are on the '' | + | So there are 1161 merge commits in the testable range, but we need to further disqualify merge commits |
| < | < | ||
| $ git rev-list v4.18..v4.19 --merges --first-parent | wc -l | $ git rev-list v4.18..v4.19 --merges --first-parent | wc -l | ||
| 426 | 426 | ||
| + | $ | ||
| + | </ | ||
| + | |||
| + | What the above set of merge commits represents are those merge commits for which we want to totally ignore all commits on the feature branch that contributed to each of those commits. For each merge commit above (call it '' | ||
| + | |||
| + | < | ||
| + | for rev in $(git rev-list v4.18..v4.19 --merges --first-parent); | ||
| + | git rev-list $rev^2 --not $rev^ | ||
| + | done | xargs git bisect skip | ||
| + | </ | ||
| + | |||
| + | Given that our basic search would have processed 15204 commits, we can count how many commits will now be pruned from the bisection: | ||
| + | |||
| + | < | ||
| + | for rev in $(git rev-list v4.18..v4.19 --merges --first-parent); | ||
| + | git rev-list $rev^2 --not $rev^ | ||
| + | done | sort | uniq | wc -l | ||
| + | 14714 | ||
| $ | $ | ||
| </ | </ | ||