1

In my current workflow, I'm updating/rebasing an ancient patch to work against recent versions of a projetct.

In my current workflow, I use git bisect to find the latest commit which can be used to cleanly apply the patch.

To check if the patch can be cleanly applied, I need to patch the files and check the exit status. This procedure changes the working directory, which is no longer clean.

Before apply the current commit as good or bad, I always use git reset --hard, but this task is annoying. Is it required or git bisect will take care of it for me?

Zombo
  • 1
  • 62
  • 391
  • 407
vinipsmaker
  • 2,215
  • 2
  • 19
  • 33

2 Answers2

1

It is a good idea to do a git reset --hard as you have been doing.

If the local changes are not affected by the checkout then it does not matter, they will just "ride along with you".

However if your local changes would be overwritten by a checkout it will create an error

$ git bisect good
Bisecting: 2 revisions left to test after this (roughly 1 step)
error: Your local changes to the following files would be overwritten by checkout:
        README
Please, commit your changes or stash them before you can switch branches.
Aborting
Zombo
  • 1
  • 62
  • 391
  • 407
  • any switch I can add to `git bisect` to forget about the working directory or stash it along? – vinipsmaker Feb 21 '14 at 05:14
  • @vinipsmaker I checked the docs and did not see anything, sorry. – Zombo Feb 21 '14 at 05:23
  • 1
    So the answer must lie somewhere else. I looked on the patch's manpage and I noticed the `--dry-run` option. I tested it and it doesn't pollute the working directory, but it will keep the non-zero exit status on failing patches. I'll use this option to change my current workflow. – vinipsmaker Feb 21 '14 at 05:43
1

I've been in exactly the same situation a few times. It is best for the tree to be in a clean state before "warping" to a completely different revision.

I ended up putting the patch into a stash.

Usually, in a bisecting situation, a good approach is to put the iteration into a single command line, which can be easily repeated from the shell history. E.g.:

$ if git stash pop ; then <command to do a clean build and test>; git stash save; fi

Then usually all that is left to do is git bisect good or git bisect bad, and re-run the above at the next tested revision. If the stash doesn't apply (the if fails), you have to either resolve it, or just declare the revision untestable with git bisect skip.

Kaz
  • 55,781
  • 9
  • 100
  • 149