Re: [PATCH 0/16] make prune mtime-checking more careful

2014-10-08 Thread Junio C Hamano
Jeff King writes: > So that explains that bug (as a side note, you might think that if we > are flipping return values, lots of things would fail when they ask "do > we have this packed object" and it erroneously says "yes". But that does > not happen. The wrong return value comes from freshening

Re: [PATCH 0/16] make prune mtime-checking more careful

2014-10-08 Thread Jeff King
On Sun, Oct 05, 2014 at 09:42:49PM -0400, Jeff King wrote: > On Sat, Oct 04, 2014 at 03:22:10PM -0700, Junio C Hamano wrote: > > > This applied on top of 'maint' (which does have c40fdd01) makes the > > test #9 (prune: do not prune detached HEAD with no reflog) fail. > > I'll fix the bone-headed

Re: [PATCH 0/16] make prune mtime-checking more careful

2014-10-05 Thread Jeff King
On Sat, Oct 04, 2014 at 03:22:10PM -0700, Junio C Hamano wrote: > This applied on top of 'maint' (which does have c40fdd01) makes the > test #9 (prune: do not prune detached HEAD with no reflog) fail. I'll fix the bone-headed error returns that René noticed and double check that they were the com

Re: [PATCH 0/16] make prune mtime-checking more careful

2014-10-05 Thread René Scharfe
Am 05.10.2014 um 00:22 schrieb Junio C Hamano: Jeff King writes: There's quite a lot of patches here, but most of them are preparatory cleanups. The meat is in patches 13, 15, and 16. [01/16]: foreach_alt_odb: propagate return value from callback [02/16]: isxdigit: cast input to unsigne

Re: [PATCH 0/16] make prune mtime-checking more careful

2014-10-04 Thread Junio C Hamano
Jeff King writes: > There's quite a lot of patches here, but most of them are preparatory > cleanups. The meat is in patches 13, 15, and 16. > > [01/16]: foreach_alt_odb: propagate return value from callback > [02/16]: isxdigit: cast input to unsigned char > [03/16]: object_array: factor ou

Re: [PATCH 0/16] make prune mtime-checking more careful

2014-10-03 Thread Junio C Hamano
Jeff King writes: > ... The objects are removed by prune, which doesn't realize > that they are part of an ongoing operation. Prune uses the filesystem > mtime to determine this, but we are not very thorough in making sure > that is kept up to date. The whole series looked quite sensible. Thank

[PATCH 0/16] make prune mtime-checking more careful

2014-10-03 Thread Jeff King
At GitHub we've occasionally run across repos getting corrupted by trees and blobs near the tip going missing. We do a lot of "test merges" between branches and HEAD (this is what feeds the "OK to merge" button on the web interface), and the objects are almost always related to these merges. The ob