1

I was running a difference checker between my current files and a backup of the files on my external drive, and I found some differences between a git repo and it's backup. The only differences were some extra files under .git/objects on the left side and two blank .git/objects/info and .git/objects/pack folders on the right. I did a quick git show and git log on both sides, which gave identical outputs.

Then I did a git fsck --no-reflogs, and found one extra dangling commit on the left side. Iteratively git ls-treeing my way down that extra commit gave me a bunch of trees and blobs that accounted for all but one of the extra files on the left side.

Using git cat-file -t <sha1> on that one last file told me it was a tree. However, I have used git ls-tree on every commit and still found no reference to this mysterious tree object. So where exactly did this file come from? I'm 99.99% sure it doesn't matter, just curious :P

Chris Maes
  • 35,025
  • 12
  • 111
  • 136
woojoo666
  • 7,801
  • 7
  • 45
  • 57
  • I actually found quite a lot git repo's that followed the same pattern: extra objects on the left side, empty /info and /pack folders on the right side. I did change Git clients, which I'm guessing caused all these discrepancies. Nonetheless, I'm still curious where this specific extra file is coming from – woojoo666 Feb 23 '15 at 12:52
  • Running `diff` or anything similar against two different repos, even if they currently have the exact same state with regards to branch heads, remotes, local commits and working directory, is not ever going to be a reliable comparison method due to at least the packed/unpacked state of objects, the frequency of garbage collection runs, reflogs, and a few other possible causes... – twalberg Feb 23 '15 at 16:35
  • Interesting, I guess I'll have to read up a bit on those topics. Yeah i had a suspicion I was going too far down the rabbit hole, but this was a relatively small repo (4-5 commits) so I thought it'd be a good chance to see how git actually worked – woojoo666 Feb 23 '15 at 21:29

1 Answers1

1

meh, rookie mistake. Turns out, the extra dangling commit was pointing directly to the missing tree. I thought that doing git ls-tree <sha1> on a commit object would give the tree it was pointing to, but it actually gives the children of the tree it's pointing to. Using git cat-file -p <sha1>, which finds object contents, gave me the info I needed.

So it seems like all files in .git/objects are either commits or dangling commits. I found this to be a great concise guide to how git objects work.

woojoo666
  • 7,801
  • 7
  • 45
  • 57