On Thu, May 14, 2015 at 12:33:02PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > On Thu, May 14, 2015 at 12:19:25PM -0700, Junio C Hamano wrote: > > > >> > It looks like we need to pay more attention to the return value of > >> > setup_rerere, which is what is supposed to take the lock. > >> > >> Good spotting. The normal rerere does check, but rerere-forget > >> codepath seems to forget it. > > > > Here's a patch. > > Thanks. This is obviously correct to fix your "init -q" one. > > I am still puzzled by the original, though. I assumed that rerere > was enabled and working correctly (in the sense that it correctly > replayed a mistaken resolution recorded earlier, which Alex wanted > to correct by forgetting). Yeah, agreed. I don't see any other code paths that could end up trying to commit a lock we haven't taken, though. Alex, can you tell us more about your repository? And possibly show us the output of: ls -d .git/rr-cache git config rerere.enabled in the repository? -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html