3

You can pass a list of paths to git bisect so that only commits changing those files are tested:

You can further cut down the number of trials, if you know what part of the tree is involved in the problem you are tracking down, by specifying path parameters when issuing the bisect start command:

$ git bisect start -- arch/i386 include/asm-i386

However, I would like to do the dual of this: ignore commits that only touch certain files, so something like

$ git bisect start --unrelated arch/i386 include/asm-i386

would skip a commit that touches arch/i386/foo.c and include/asm-i386/utils.s but would include a commit that touches arch/i386/bar.c and arch/amd64/baz.c (since the latter is not under the listed paths and thus the whole commit is relevant).

Is there a way to do that?

Cactus
  • 27,075
  • 9
  • 69
  • 149

2 Answers2

3

The way to do what you want is to use the bisect run <script>.
Use the bisect as you did so far and use the bisect with the script option.

The script will return the appropriate code for skipping (or 125 for not testable - much more suitable in your case).

Note that the script (my_script in the above example) should exit with code 0 if the current source code is good, and exit with a code between 1 and 127 (inclusive), except 125, if the current source code is bad.

Any other exit code will abort the bisect process. It should be noted that a program that terminates via "exit(-1)" leaves $? = 255, (see the exit(3) manual page), as the value is chopped with "& 0377".

The special exit code 125 should be used when the current source code cannot be tested. If the script exits with this code, the current revision will be skipped (see git bisect skip above). 125 was chosen as the highest sensible value to use for this purpose, because 126 and 127 are used by POSIX shells to signal specific error status (127 is for command not found, 126 is for command found but not executable---these details do not matter, as they are normal errors in the script, as far as "bisect run" is concerned).

Community
  • 1
  • 1
CodeWizard
  • 128,036
  • 21
  • 144
  • 167
1

As codeWizar says, you should probably use a script for this method

Write:

git bisect start HEAD commit-id

Have a script.sh like this:

[ "$(git diff-tree --no-commit-id --name-only -r HEAD | sort)" = "path"  ] && exit 125
make && exit 0 || exit 1

and run 

git bisect run script.sh

The line:

[ "$(git diff-tree --no-commit-id --name-only -r HEAD | sort)" = "path"  ] && exit 125

will test wether the current commit contains exactly the file changes path and will exit 125 if it is the case (eg skip that commit for bisecting)

You can also specify multiple paths with \n inside path

edi9999
  • 19,701
  • 13
  • 88
  • 127
  • But doesn't this return "uninteresting" for commits that contain changes in `path`, even when there are also changes outside `path`? – Cactus Jun 29 '15 at 10:56
  • Right, I have updated my answer using `git diff-tree --no-commit-id --name-only -r HEAD | sort` which gives you the list of changed files for HEAD – edi9999 Jun 29 '15 at 11:05
  • On second read, this is still unsatisfactory because this requires the testing to be fully automatable. In my scenario, I have a mostly manual process for deciding if a given commit is `good` or `bad`, and I don't see a way for `script.sh` to signal that "this commit is not to be skipped, but needs manual testing". – Cactus Jun 30 '15 at 01:28
  • 1
    You can also run the bisect manually with "git bisect good / git bisect bad", and run `[ "$(git diff-tree --no-commit-id --name-only -r HEAD | sort)" = "path" ] && git bisect skip` before each test – edi9999 Jun 30 '15 at 09:24