Problem with rerere forget

Problem with rerere forget

[Alex Coppens]

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

Re: Problem with rerere forget

[Stefan Beller]

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

Re: Problem with rerere forget

[Alex Coppens]

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 <sbeller@google.com> wrote:
> 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

Re: Problem with rerere forget

[Stefan Beller]

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

Re: Problem with rerere forget

[Junio C Hamano]

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?

Re: Problem with rerere forget

[Jeff King]

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.

-Peff

Re: Problem with rerere forget

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

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

Good spotting.  The normal rerere does check, but rerere-forget
codepath seems to forget it.

[PATCH] rerere: exit silently on "forget" when rerere is disabled

[Jeff King]

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);
-- 
2.4.1.396.g7ba6d7b

Re: [PATCH] rerere: exit silently on "forget" when rerere is disabled

[Junio C Hamano]

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

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

Re: [PATCH] rerere: exit silently on "forget" when rerere is disabled

[Jeff King]

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

Re: [PATCH] rerere: exit silently on "forget" when rerere is disabled

[Alex Coppens]

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

Re: [PATCH] rerere: exit silently on "forget" when rerere is disabled

[Jeff King]

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

Re: [PATCH] rerere: exit silently on "forget" when rerere is disabled

[Alex Coppens]

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