Problem with rerere forget

> _______________
>
>
> 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".

>
> 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

> On Thu, May 14, 2015 at 11:05 AM, Alex Coppens <alex@nativetouch.com> 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 <alex@nativetouch.com> 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?

> On Thu, May 14, 2015 at 11:49:12AM -0700, Junio C Hamano wrote:
>
>> Alex Coppens <alex@nativetouch.com> 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.

> > 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.

> 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@peff.net>
> ---
>  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 <peff@peff.net> 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).

> On Thu, May 14, 2015 at 12:33:02PM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> 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

> 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.

> 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