Help intended for the benefit of users who do not use git regularly, but may want to recompile Wine for RegressionTesting or experimenting with small bugs and features. It is being started by a novice who is learning as he goes, so any advice here should be taken with several grains of salt until it has been audited and corrected by experts.

What do you do if some versions do not compile? If you want to analyze the regions both before and after the bad area, you will need to get a list of the versions and restart bisect from intermediate versions within the repository.

Usually you can track down the problem to between two official releases, and I recommend you try to do so before using intermediate versions. For example, you can choose: git bisect start / git bisect bad / git bisect good wine-0.9.33 if you want to, to search from a known point to the latest version. But if you know 0.9.43 fails, you can save effort by using a git bisect bad wine-0.9.43 instead. I would recommend following the standard procedure, of saying nothing but git bisect good or git bisect bad, until you either find the first bad version or have a problem because of multiple bugs or failure to build. Only then will you need to understand the intermediate versions. Even if I need to restart a bisection, I would normally restart it at a release version until I have pinned the problem down to between two releases.

Once you find a problem area, you may want to try nearby versions as suggested (I had trouble with the reset HEAD command, perhaps just because I didn't trust it or know if it had done its job, when the failure to build persisted). If you decide you want to "skip over" a few, since failures may persist for a few versions, you can do git bisect reset then begin again in a new place. Of course once you do that, you will have to keep track of where you have tested, since bisect can no longer do it automatically.

(Question: would it work to use good and bad the same, build and test, as a manual bisection procedure? Maybe there's an easier way to get that effect when desired.)

Answer: To do this, use git reset. For example, to build wine 0.9.43, you would use:

git reset --hard wine-0.9.43

When you do a build, the version printed will usually begin with the last release name, followed by a g (always the same?) and seven hexadecimal digits. If you find the first version that fails without any build errors, you can report the printed version, as that is sufficient for a developer to find the right spot. Those seven digits are the first part of a 24-digit number which uniquely identifies the version within the repository.

You may eventually need a listing of the intermediate versions. You can use gitk, which is a gui. To get fast response from it, give it a starting version with two periods, so that it does not need to process earlier versions than that. For example, you might use "gitk wine-0.0.33.." to be sure you have the earliest one you need. Also, gitk will end at the end of your bisect region. You may want to reset (is it easy to set this up without doing both good and bad commands? should I recommend deleting the bisect branch? How about limiting the end point to a released version if I don't re-bisect to do it?). You may prefer to use the git-log command instead, probably with the --pretty=oneline option and diverting output to a file, like "git log --pretty=oneline wine-0.9.33..wine-0.9.44 > allversions.list". I prefer to do that once for the whole range I'm interested in, then I may use the line numbers in my notes. Also, you can search for the 7-hex-digit values that appear in built versions. The "git bisect log" command will show the current bisection (since last start or --some-- resets). gitk is handy because it shows all details, including exact patches. I don't know how to set it's range except with bisect reset though; perhaps one could set up another branch which gives gitk its limits?

I would like to add a couple of examples to this.

• Please contact me ( nick Amorphous ) or someone else who is willing to help on IRC as it is much easier there to clarify things and answer question. I think git bisect log and git bisect replay may make some things easier for you. Also it would probably be best to integrate things that got clarified back into the page RegressionTesting. -- JanZerebecki 2007-09-25 08:23:04

"fatal: ref HEAD is not a symbolic ref" when running git bisect

You need to "git checkout master".