# Problem with rerere forget 13 messages from 2015-05-14 to 2015-05-14. Participants: Alex Coppens, Stefan Beller, Junio C Hamano, Jeff King. Thread: https://gitlist.dev/t/39338 ## Alex Coppens, 2015-05-14 18:05 Subject: Problem with rerere forget Message-ID: URL: https://gitlist.dev/e/CAPt1q6fMMz61aZEJB9b%2BK6%2BkHFwkm%2BbMYXoKBj78GNJU%2BdWioA%40mail.gmail.com ``` Hello there, So I am trying to make git forget a conflict resolution: _______________ git rerere forget path_to_file/file.js fatal: BUG: attempt to commit unlocked object _______________ Google doesn't seem to know the answer: No results found for "fatal: BUG: attempt to commit unlocked object". I think I am using rerere forget the wrong way. Can someone help? Regards, Alex ``` ## Stefan Beller, 2015-05-14 18:21 Subject: Re: Problem with rerere forget Message-ID: URL: https://gitlist.dev/e/CAGZ79kZ8Cy1Pp9cf7vExntbfe-YW5KjYx6Fogr3O94wDfwuOXg%40mail.gmail.com In-Reply-To: ``` On Thu, May 14, 2015 at 11:05 AM, Alex Coppens wrote: > Hello there, > > So I am trying to make git forget a conflict resolution: Which version of git do you run? > _______________ > > > git rerere forget path_to_file/file.js > > fatal: BUG: attempt to commit unlocked object > > _______________ > > Google doesn't seem to know the answer: No results found for "fatal: > BUG: attempt to commit unlocked object". see: https://github.com/git/git/blob/master/lockfile.c#L316 (The "fatal:" will be added by the call to die) > > > I think I am using rerere forget the wrong way. Can someone help? (I don't think you're doing it wrong.) The "BUG:" errors are a hint that the internal implementation of git is broken, which should be fixed, thanks for reporting! We'd need to find out where/how git broke and fix that. If it's a hard fix, we'd need to have a better error message at least. Can you provide an example repository which reproduces this failure? Or better yet, can you git bisect git itself to find out when the error was introduced? Thanks, Stefan > > Regards, > > Alex > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ``` ## Alex Coppens, 2015-05-14 18:40 Subject: Re: Problem with rerere forget Message-ID: URL: https://gitlist.dev/e/CAPt1q6d3euApCKLUBjssyfBmeVw0TVYOqDmTZL79gN1TvtxdsA%40mail.gmail.com In-Reply-To: ``` I use git version 2.2.1. I cannot provide an example repository that reproduces the error. What does git bisect do? Alex On Thu, May 14, 2015 at 2:21 PM, Stefan Beller wrote: > On Thu, May 14, 2015 at 11:05 AM, Alex Coppens wrote: >> Hello there, >> >> So I am trying to make git forget a conflict resolution: > > Which version of git do you run? > >> _______________ >> >> >> git rerere forget path_to_file/file.js >> >> fatal: BUG: attempt to commit unlocked object >> >> _______________ >> >> Google doesn't seem to know the answer: No results found for "fatal: >> BUG: attempt to commit unlocked object". > > see: https://github.com/git/git/blob/master/lockfile.c#L316 > (The "fatal:" will be added by the call to die) > >> >> >> I think I am using rerere forget the wrong way. Can someone help? > > (I don't think you're doing it wrong.) > > The "BUG:" errors are a hint that the internal implementation of git is broken, > which should be fixed, thanks for reporting! We'd need to find out where/how > git broke and fix that. If it's a hard fix, we'd need to have a better > error message > at least. > > Can you provide an example repository which reproduces this failure? > Or better yet, can you git bisect git itself to find out when the > error was introduced? > > Thanks, > Stefan > >> >> Regards, >> >> Alex >> -- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ``` ## Junio C Hamano, 2015-05-14 18:49 Subject: Re: Problem with rerere forget Message-ID: URL: https://gitlist.dev/e/xmqq7fsbkn9z.fsf%40gitster.dls.corp.google.com In-Reply-To: ``` Alex Coppens writes: > git rerere forget path_to_file/file.js > > fatal: BUG: attempt to commit unlocked object That comes from commit_lock_file(); I think rerere.c:write_rr() has a call to that function and I suspect that is the call that is giving the above message. Is there any other process that is mucking with your .git/index file while you are running the command? ``` ## Stefan Beller, 2015-05-14 18:57 Subject: Re: Problem with rerere forget Message-ID: URL: https://gitlist.dev/e/CAGZ79kZC-Kn4FbHgkifeDew7_qpGJSFDaqO%3DF%3Dbok1FUzm%3D1Ew%40mail.gmail.com In-Reply-To: ``` On Thu, May 14, 2015 at 11:40 AM, Alex Coppens wrote: > I use git version 2.2.1. I cannot provide an example repository that > reproduces the error. > > What does git bisect do? git bisect looks at the git history and performs a binary search on it to find the commit which introduced a bug. http://git-scm.com/docs/git-bisect To find the bug that way, you'd need to get the source code of git and compile it yourself though (multiple times until the bug is found) ``` ## Jeff King, 2015-05-14 19:16 Subject: Re: Problem with rerere forget Message-ID: <20150514191637.GA9329@peff.net> URL: https://gitlist.dev/e/20150514191637.GA9329%40peff.net In-Reply-To: ``` On Thu, May 14, 2015 at 11:49:12AM -0700, Junio C Hamano wrote: > Alex Coppens writes: > > > git rerere forget path_to_file/file.js > > > > fatal: BUG: attempt to commit unlocked object > > That comes from commit_lock_file(); I think rerere.c:write_rr() > has a call to that function and I suspect that is the call that is > giving the above message. > > Is there any other process that is mucking with your .git/index file > while you are running the command? This seems much easier to reproduce: $ git init -q $ git rerere forget foo fatal: BUG: attempt to commit unlocked object 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. -Peff ``` ## Junio C Hamano, 2015-05-14 19:19 Subject: Re: Problem with rerere forget Message-ID: URL: https://gitlist.dev/e/xmqqr3qjj7b6.fsf%40gitster.dls.corp.google.com In-Reply-To: <20150514191637.GA9329@peff.net> ``` Jeff King writes: > On Thu, May 14, 2015 at 11:49:12AM -0700, Junio C Hamano wrote: > >> Alex Coppens writes: >> >> > git rerere forget path_to_file/file.js >> > >> > fatal: BUG: attempt to commit unlocked object >> >> That comes from commit_lock_file(); I think rerere.c:write_rr() >> has a call to that function and I suspect that is the call that is >> giving the above message. >> >> Is there any other process that is mucking with your .git/index file >> while you are running the command? > > This seems much easier to reproduce: > > $ git init -q > $ git rerere forget foo > fatal: BUG: attempt to commit unlocked object > > 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. ``` ## Jeff King, 2015-05-14 19:20 Subject: [PATCH] rerere: exit silently on "forget" when rerere is disabled Message-ID: <20150514192052.GB9329@peff.net> URL: https://gitlist.dev/e/20150514192052.GB9329%40peff.net In-Reply-To: ``` 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 --- 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 ``` ## Junio C Hamano, 2015-05-14 19:33 Subject: Re: [PATCH] rerere: exit silently on "forget" when rerere is disabled Message-ID: URL: https://gitlist.dev/e/xmqqmw17j6oh.fsf%40gitster.dls.corp.google.com In-Reply-To: <20150514192052.GB9329@peff.net> ``` Jeff King 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). > > -- >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 > --- > 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); ``` ## Jeff King, 2015-05-14 20:22 Subject: Re: [PATCH] rerere: exit silently on "forget" when rerere is disabled Message-ID: <20150514202207.GA13541@peff.net> URL: https://gitlist.dev/e/20150514202207.GA13541%40peff.net In-Reply-To: ``` On Thu, May 14, 2015 at 12:33:02PM -0700, Junio C Hamano wrote: > Jeff King 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 ``` ## Alex Coppens, 2015-05-14 20:51 Subject: Re: [PATCH] rerere: exit silently on "forget" when rerere is disabled Message-ID: URL: https://gitlist.dev/e/CAPt1q6dhZarACvYQM5HFTGg3xA%3DLjnhF7DP8B6K%2BFa1%3Dm2Of9w%40mail.gmail.com In-Reply-To: <20150514202207.GA13541@peff.net> ``` Here are the outputs I have: $ ls -d .git/rr-cache ls: .git/rr-cache: No such file or directory $ git config rerere.enabled $ My repository is a ruby on rails project, I am currently on the development branch. It's a private repository hosted on Github. Not sure what other information you want. Alex On Thu, May 14, 2015 at 4:22 PM, Jeff King wrote: > On Thu, May 14, 2015 at 12:33:02PM -0700, Junio C Hamano wrote: > >> Jeff King 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 ``` ## Jeff King, 2015-05-14 20:56 Subject: Re: [PATCH] rerere: exit silently on "forget" when rerere is disabled Message-ID: <20150514205617.GA14836@peff.net> URL: https://gitlist.dev/e/20150514205617.GA14836%40peff.net In-Reply-To: ``` On Thu, May 14, 2015 at 04:51:25PM -0400, Alex Coppens wrote: > Here are the outputs I have: > > $ ls -d .git/rr-cache > ls: .git/rr-cache: No such file or directory > > $ git config rerere.enabled > $ > > My repository is a ruby on rails project, I am currently on the > development branch. It's a private repository hosted on Github. Not > sure what other information you want. OK, so it looks like rerere is not enabled (and my patch will fix the case you saw). But then I am puzzled why you were running "rerere forget" in the first place. Just experimenting, or did you expect it to do something? -Peff ``` ## Alex Coppens, 2015-05-14 20:59 Subject: Re: [PATCH] rerere: exit silently on "forget" when rerere is disabled Message-ID: URL: https://gitlist.dev/e/CAPt1q6fNtTvjtXFs%2BBO1Kgpkn9pkdJkqN7uwJUK%3DzE4%3DatrOnA%40mail.gmail.com In-Reply-To: <20150514205617.GA14836@peff.net> ``` I really thought my boss setup rerere on my project a while ago. I had a merge without conflicts that went wrong (the whole app breaking because of a missing comma) so I assumed a conflict was automatically resolved. Alex On Thu, May 14, 2015 at 4:56 PM, Jeff King wrote: > On Thu, May 14, 2015 at 04:51:25PM -0400, Alex Coppens wrote: > >> Here are the outputs I have: >> >> $ ls -d .git/rr-cache >> ls: .git/rr-cache: No such file or directory >> >> $ git config rerere.enabled >> $ >> >> My repository is a ruby on rails project, I am currently on the >> development branch. It's a private repository hosted on Github. Not >> sure what other information you want. > > OK, so it looks like rerere is not enabled (and my patch will fix the > case you saw). But then I am puzzled why you were running "rerere > forget" in the first place. Just experimenting, or did you expect it to > do something? > > -Peff ```