3

I just ran a Git bisect and got the following output:

547b115c69ab2ac7fde285c9b5653cbd8309a930 is the first bad commit
commit 547b115c69ab2ac7fde285c9b5653cbd8309a930
Author: Václav Slavík <vaclav@slavik.io>
Date:   Sat Mar 14 13:35:32 2015 +0100

    Use a floating tool window for Find

    Keep the window on top of the parent frame at all times, don't show it
    in taskbar and use the small "inspector" window decorations on OS X. The
    latter is what couldn't be accomplished with wxDialog, so change to
    using wxFrame and make the necessary changes.

:040000 040000 b1ed63b681bd41f924cbcf8214d65b65d7c2ea48 958a44d35851dae34b62d198a6b7f5685f490c89 M  src

I understand everything except the: 

040000 040000 b1ed63b681bd41f924cbcf8214d65b65d7c2ea48 958a44d35851dae34b62d198a6b7f5685f490c89 M   src

What does "040000" mean? What do the hashes refer to?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Alex Henrie
  • 744
  • 1
  • 6
  • 17

1 Answers1

3

This is about the path parameter within the first bad commit which has changes triggering the error.

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

You can see more in "Fighting regressions with git bisect":

And after a few more steps like that, "git bisect" will eventually find a first bad commit:

$ git bisect bad
2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit
commit 2ddcca36c8bcfa251724fe342c8327451988be0d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat May 3 11:59:44 2008 -0700

    Linux 2.6.26-rc1

:100644 100644 5cf82581... 4492984e... M      Makefile

The hashes are the SHA1 associated with the blob or tree which was passed as a parameter (SHA1 for the good commit vs. SHA for the first bad commit), in order to facilitate a diff.

In your case, "040000" is a file mode, one of:

  • 100644 for file (blob),
  • 100755 for executable (blob),
  • 040000 for subdirectory (tree),
  • 160000 for submodule (commit), or
  • 120000 for a blob that specifies the path of a symlink
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • The bisect was done on a local copy of the https://github.com/vslavik/poedit repository. I started the bisect with `git bisect start && git bisect good v1.7.5-oss && git bisect bad`. So I would expect to see ce8a284 and 547b115 in the final output, not b1ed63b and 958a44d which don't refer to any commits at all. So what are b1ed63b and 958a44d? – Alex Henrie Apr 24 '15 at 05:55
  • @AlexHenrie: no b1ed63b is the index of a *blob* or *tree*, not of a *commit*. b1ed63b references the object (blob here) of the repo which makes the test fails. 547b115 at the beginning is the first bad commit. Remember that a commit references a tree which references other trees or blob (http://www.pointsoftware.ch/wp-content/uploads/2012/07/18333fig0301-tn.png). At the end of bisect output, you see SHA1 of blob or tree, not commit. – VonC Apr 24 '15 at 06:12