For certain commits in our repo (but not all), if I check out the commit, then return to the master branch, I get an unexpected warning about commits being left behind:

# Check out one of the commits in question:
$ git checkout dd33caa5b004b0e3bd449152f9335e40450db91c
Note: checking out 'dd33caa5b004b0e3bd449152f9335e40450db91c'.
You are in 'detached HEAD' state. You can look around, make experimental
[...]
HEAD is now at dd33caa... Organized DataStore build files, added cleanup targets.
# Now switch back to the master branch so I can work:
$ git checkout master
Warning: you are leaving 17 commits behind, not connected to
any of your branches:
dd33caa Organized DataStore build files, added cleanup targets.
4916eec Fixes to C++ codegen to use maven features.
a26291d Merge branch 'master' of [redacted origin repo address]
93ae0b9 Add protobuf 2.4.1 jar file to install scripts. Add QTDIR to build script.
... and 13 more.
If you want to keep them by creating a new branch, this may be a good time
to do so with:
git branch new_branch_name dd33caa5b004b0e3bd449152f9335e40450db91c
Switched to branch 'master'

All the commits in question (as far as I can tell) are reachable from master, and I haven't made any commits while in the detached head state (this is a clean clone of our repository). The master branch's history looks like this:

Any idea what might be going on here? It appears to be connected to one specific user's commits, and I can reproduce this with Git 1.7.9.6 on OSX and with Git 1.7.9.5 on Ubuntu, but not with 1.8.0 on Ubuntu... so a Git bug, perhaps? I don't see anything that looks relevant in the release notes, though...

Is dd33caa in fact a parent commit of ecaa2f5? I know it looks that way, but orphan branches (git checkout --orphan newbranch) show up like that when you do git log --graph --pretty=oneline --all, as well...
–
twalbergNov 20 '12 at 19:31

Yes, it is (can't show you, though, due to the limitations of this comment form).
–
JonathonWNov 20 '12 at 20:33

Hmm.... Not sure what other "normal" scenarios would result in that situation, so that tends to suggest a bug...
–
twalbergNov 20 '12 at 20:49

1 Answer
1

Yes, this looks like a Git bug. If you care to find out what fixed it, you can do a bisection. Clone git.git, checkout a version that is broken and verify that the problem occurs, check out the latest and verify that it's fixed, and then run a bisection to find which commit fixed the problem:

Yep, found the bug and its fix. It's a reporting bug that happens if a commit previously at the detached HEAD is only reachable via a commit that happens to be pointed at by a symbolic ref... the bug was fixed in add416a, back in June.
–
JonathonWNov 20 '12 at 21:25

@JonathonW: this bug was fixed in add416a, which was released in Git version v1.7.11.5.
–
FlimmApr 2 '14 at 10:27