Thread (4 messages) flat view 4 messages, 4 authors, 2016-06-15

Re: Missing Refs after Garbage Collection

From: Martin Fick <hidden>
Date: 2016-06-15 22:55:38

On Friday, December 21, 2012 06:41:43 pm Earl Gresh wrote:
Hi-

I have observed that after running GC, one particular git
repository ended up with some missing refs in the
refs/changes/* namespace the Gerrit uses for storing
patch sets. The refs were valid and should not have been
pruned. Concerned about loosing data, GC is still enabled
but ref packing is turned off. Now the number of refs has
grown to the point that it's causing performance problems
when cloning the project.

Is anyone familiar with git gc deleting valid references?
I'm running git version 1.7.8. Have there been any
patches in later git releases that might address this
issue ( if it is a git problem )?

When Earl was testing ref-packing a few months ago, that the 
refs in question where reported invalid by git show-ref:

  git show-ref 2>&1 |grep refs/changes/45/129345/1
  error: refs/changes/45/129345/1 does not point to a valid 
object!

But we could trace the refs manually to git show-object just 
fine.  But oddly enough, when using git show-ref with the -v, 
the error above would not be spit out.

So, my guess is that something during the repack was 
following the same code path that git show-ref (without the -
v) was following and determining that the ref was invalid and 
therefor it was not able to add it to the new packfile, but 
yet perhaps it was still being added to the prune-list and 
thus getting pruned?  Is this possible somehow?  

Looking at handle_one_ref() I can't see how.  The fprintf() 
happens before the ref is added to the prune list and is 
unconditional.  I am grasping here, but what if the sha1 
passed into handle_one_ref() somehow gets set incorrectly to 
000...?  Would it then basically get written to the packed-
ref file as 000... (deleted), but then still get added to the 
prune list?  You might say "but then it wouldn't get pruned 
since the loose ref doesn't match 000..., but if the logic 
which checks this matching makes the same error reading the 
sha1 and thinks it is 000... it might then get pruned?


-Martin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help