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