git_bisect

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
git_bisect [2019/02/26 21:44] – [Bisection while ignoring feature branches] rpjdaygit_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 ''master'' branch, and we try to bisect using those two commits as good and bad endpoints, it's entirely possible that we could end up processing many, many, many commits based on the number of (potentially lengthy) feature branches that were merged into ''master'' between the two commits. If we have two commits directly on the ''master'' branch, and we try to bisect using those two commits as good and bad endpoints, it's entirely possible that we could end up processing many, many, many commits based on the number of (potentially lengthy) feature branches that were merged into ''master'' between the two commits.
  
-Rather than bisecting completely on those lengthy feature branches, we can restrict the search to just those commits where feature branches were merged into ''master'', so the ultimate goal is to say, "//That// merged feature branch is the one that caused the problem," possibly inspiring another round of more focused bisection. (This also considers the possibility of a stand-alone commit directly on the feature branch as well.) +Rather than bisecting completely on those lengthy feature branches, we can restrict the search to just those commits where feature branches were merged into ''master'', so the ultimate goal is to say, "//That// merged feature branch is the one that caused the problem," possibly inspiring another round of more focused bisection. (This also considers the possibility of a stand-alone commit directly on the ''master'' branch as well.) Let's demonstrate this using the Linux kernel source repository, defining ''v4.18'' as the good commit, and ''v4.19'' as the bad commit.
- +
-Let's demonstrate this using the Linux kernel source repository, defining ''v4.18'' as the good commit, and ''v4.19'' as the bad commit.+
  
 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:
 </code> </code>
  
-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 ''git bisect skip'' to cut down on the work. The first step is to generate a list of merge commits between the two endpoints
- +
-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 ''git bisect skip'' to cut down on the work. The first step is to generate a list of merge commits between the two endpoints+
  
 <code> <code>
Line 254: Line 250:
 </code> </code>
  
-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 ''master'' branch:+So there are 1161 merge commits in the testable range, but we need to further disqualify merge commits exclusively 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 ''master'' branch:
  
 <code> <code>
Line 262: Line 258:
 </code> </code>
  
-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 of those merge commits above (call it ''rev''), we list all commits reachable from the second parent (on the feature branch, ''rev^2''), but not reachable from the parent on the master branch (''rev^''), and pass //all// such commits to ''git bisect skip''.+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 ''rev''), we list all commits reachable from the second parent (the one on the feature branch, ''rev^2''), but not reachable from the parent on the master branch (''rev^''), and pass //all// such commits to ''git bisect skip''.
  
 <code> <code>
-for rev in $(git rev-list v4.18..v419) --merges --first-parent); do+for rev in $(git rev-list v4.18..v4.19 --merges --first-parent); do
   git rev-list $rev^2 --not $rev^   git rev-list $rev^2 --not $rev^
 done | xargs git bisect skip done | xargs git bisect skip
 +</code>
 +
 +Given that our basic search would have processed 15204 commits, we can count how many commits will now be pruned from the bisection:
 +
 +<code>
 +for rev in $(git rev-list v4.18..v4.19 --merges --first-parent); do
 +  git rev-list $rev^2 --not $rev^
 +done | sort | uniq | wc -l
 +14714
 +$
 </code> </code>
  • git_bisect.1551217497.txt.gz
  • Last modified: 2019/02/26 21:44
  • by rpjday