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.
-- >8 --
Subject: rerere: exit silently on "forget" when rerere is disabled
If you run "git rerere forget foo" in a repository that does
not have rerere enabled, git hits an internal error:
$ git init -q
$ git rerere forget foo
fatal: BUG: attempt to commit unlocked object
The problem is that setup_rerere() will not actually take
the lock if the rerere system is disabled. We should notice
this and return early. We can return with a success code
here, because we know there is nothing to forget.
Signed-off-by: Jeff King <peff@xxxxxxxx>
---
rerere.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/rerere.c b/rerere.c
index 31644de..94aea9a 100644
--- a/rerere.c
+++ b/rerere.c
@@ -659,6 +659,8 @@ int rerere_forget(struct pathspec *pathspec)
return error("Could not read index");
fd = setup_rerere(&merge_rr, RERERE_NOAUTOUPDATE);
+ if (fd < 0)
+ return 0;
unmerge_cache(pathspec);
find_conflict(&conflict);
--
2.4.1.396.g7ba6d7b
--
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