Amending a merge commit doesn't update the rerere cache

Amending a merge commit doesn't update the rerere cache

[Jay Soffian]

Subject says it all, but I'll elaborate.

During the course of testing a merge, I'll sometimes realize there was
a mistake and I'll amend the merge commit. Sadly this doesn't update
the rerere cache. For now I've been doing this:

   mv .git/rr-cache .git/rr-cache.saved &&
   git rerere-train HEAD -1 &&
   rsync -av .git/rr-cache/ .git/rr-cache.saved &&
   rm -rf .git/rr-cache &&
   mv .git/rr-cache.saved .git/rr-cache

Which is quite hackish. I think amending a merge commit should
probably update the rr-cache, but I'm not sure how best to fix this.

Thoughts?

j.

[PATCH] rerere.txt: Document forget subcommand

[Michael J Gruber]

dea4562 (rerere forget path: forget recorded resolution, 2009-12-25)
introduced the forget subcommand for rerere.

Document it.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 Documentation/git-rerere.txt |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
index acc220a..a7370d3 100644
--- a/Documentation/git-rerere.txt
+++ b/Documentation/git-rerere.txt
@@ -7,7 +7,7 @@ git-rerere - Reuse recorded resolution of conflicted merges
 
 SYNOPSIS
 --------
-'git rerere' ['clear'|'diff'|'status'|'gc']
+'git rerere' ['clear'|'forget' <pathspec>|'diff'|'status'|'gc']
 
 DESCRIPTION
 -----------
@@ -40,6 +40,10 @@ This resets the metadata used by rerere if a merge resolution is to be
 aborted.  Calling 'git am [--skip|--abort]' or 'git rebase [--skip|--abort]'
 will automatically invoke this command.
 
+'forget' <pathspec>::
+
+This resets the conflict resolutions which rerere has recorded for <pathspec>.
+
 'diff'::
 
 This displays diffs for the current state of the resolution.  It is
-- 
1.7.1.511.gfbed4

Re: [PATCH] rerere.txt: Document forget subcommand

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> dea4562 (rerere forget path: forget recorded resolution, 2009-12-25)
> introduced the forget subcommand for rerere.
> ...
> diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
> index acc220a..a7370d3 100644
> --- a/Documentation/git-rerere.txt
> +++ b/Documentation/git-rerere.txt
> @@ -40,6 +40,10 @@ This resets the metadata used by rerere if a merge resolution is to be
>  aborted.  Calling 'git am [--skip|--abort]' or 'git rebase [--skip|--abort]'
>  will automatically invoke this command.
>  
> +'forget' <pathspec>::
> +
> +This resets the conflict resolutions which rerere has recorded for <pathspec>.
> +

This description is not _incorrect_ per-se, but it does not convey one
important aspect of the subcommand; unlike "clear" and "gc", "forget" only
works in the context of the _current_ conflict resolution, just like
"diff" and "status".

Perhaps s/for <pathspec>/for the current conflict in <pathspec>/ would be
a sufficient improvement?

Re: [PATCH] rerere.txt: Document forget subcommand

[Jay Soffian]

On Tue, Jun 15, 2010 at 12:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> +'forget' <pathspec>::
>> +
>> +This resets the conflict resolutions which rerere has recorded for <pathspec>.
>> +
>
> This description is not _incorrect_ per-se, but it does not convey one
> important aspect of the subcommand; unlike "clear" and "gc", "forget" only
> works in the context of the _current_ conflict resolution, just like
> "diff" and "status".
>
> Perhaps s/for <pathspec>/for the current conflict in <pathspec>/ would be
> a sufficient improvement?

Also, pathspec is optional.

j.

Re: [PATCH] rerere.txt: Document forget subcommand

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 15.06.2010 18:37:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> dea4562 (rerere forget path: forget recorded resolution, 2009-12-25)
>> introduced the forget subcommand for rerere.
>> ...
>> diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
>> index acc220a..a7370d3 100644
>> --- a/Documentation/git-rerere.txt
>> +++ b/Documentation/git-rerere.txt
>> @@ -40,6 +40,10 @@ This resets the metadata used by rerere if a merge resolution is to be
>>  aborted.  Calling 'git am [--skip|--abort]' or 'git rebase [--skip|--abort]'
>>  will automatically invoke this command.
>>  
>> +'forget' <pathspec>::
>> +
>> +This resets the conflict resolutions which rerere has recorded for <pathspec>.
>> +
> 
> This description is not _incorrect_ per-se, but it does not convey one
> important aspect of the subcommand; unlike "clear" and "gc", "forget" only
> works in the context of the _current_ conflict resolution, just like
> "diff" and "status".

Does "current context" mean

- any recorded resolutions for the hunks which are currently recorded as
in in conflict

or

- the resolution which has (just) been recorded for the current conflict?

I'm completely agnostic of the underlying implementation of rerere (as
demonstrated by my questions probably...).

> Perhaps s/for <pathspec>/for the current conflict in <pathspec>/ would be
> a sufficient improvement?

I guess that would mean 2 above?

In any case, rerere forget is not a solution for the original "amend
merge commit and forget previous resolution" question, I guess (I just
happened to note it's undocumented). One would have to redo the merge to
get the conflict info into the index, right?

Michael

Re: [PATCH] rerere.txt: Document forget subcommand

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Junio C Hamano venit, vidit, dixit 15.06.2010 18:37:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>> +'forget' <pathspec>::
>>> +
>>> +This resets the conflict resolutions which rerere has recorded for <pathspec>.
>> 
>> This description is not _incorrect_ per-se, but it does not convey one
>> important aspect of the subcommand; unlike "clear" and "gc", "forget" only
>> works in the context of the _current_ conflict resolution, just like
>> "diff" and "status".
>
> Does "current context" mean
>
> - any recorded resolutions for the hunks which are currently recorded as
> in in conflict
>
> or
>
> - the resolution which has (just) been recorded for the current conflict?

The latter.  You can have more than one rerere database entries for the
same path (i.e. merge conflict resolutions for unrelated branches, each of
which changes unrelated things that happen to be in the same path).  The
entries in the rerere database are "when we see a conflict of this shape
(anywhere), the user wants to resolve it this way", indexed by the shape
of the conflict.  There is no "path" recorded in the database.

When "rerere forget" is run, it needs to be told which entry to forget,
and this is done by regenerating the conflict you just had (and possibly
have already resolved, if you are using recent enough git that knows
"resolve undo") using the information in the index, and <pathspec> is used
to limit this set (i.e. when you have more than one path conflicted in the
current merge).

> In any case, rerere forget is not a solution for the original "amend
> merge commit and forget previous resolution" question, I guess (I just
> happened to note it's undocumented). One would have to redo the merge to
> get the conflict info into the index, right?

Once you write the result of a merge out to a tree, the tree does not even
know if there was a conflict.  It does not know how you arrived to that
state in general.  You simply don't have enough information after reading
a tree into your index in order to "amend" it.  When reading a tree that
belongs to a merge commit into the index, we _could_ try to regenerate the
conflicted state and immediately resolve them to the tree's state but I
don't think it is worth the cost and complexity.  Besides, at that point
you do not even know what merge strategy (and which version of that
strategy) was originally used.

[PATCHv2] rerere.txt: Document forget subcommand

[Michael J Gruber]

dea4562 (rerere forget path: forget recorded resolution, 2009-12-25)
introduced the forget subcommand for rerere.

Document it.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
This somewhat fell under all radars.

v2 takes into account suggestions by Junio and Jay.

 Documentation/git-rerere.txt |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
index acc220a..db99d47 100644
--- a/Documentation/git-rerere.txt
+++ b/Documentation/git-rerere.txt
@@ -7,7 +7,7 @@ git-rerere - Reuse recorded resolution of conflicted merges
 
 SYNOPSIS
 --------
-'git rerere' ['clear'|'diff'|'status'|'gc']
+'git rerere' ['clear'|'forget' [<pathspec>]|'diff'|'status'|'gc']
 
 DESCRIPTION
 -----------
@@ -40,6 +40,11 @@ This resets the metadata used by rerere if a merge resolution is to be
 aborted.  Calling 'git am [--skip|--abort]' or 'git rebase [--skip|--abort]'
 will automatically invoke this command.
 
+'forget' <pathspec>::
+
+This resets the conflict resolutions which rerere has recorded for the current
+conflict in <pathspec>.  The <pathspec> is optional.
+
 'diff'::
 
 This displays diffs for the current state of the resolution.  It is
-- 
1.7.1.621.g01d76

Re: Amending a merge commit doesn't update the rerere cache

[Johannes Sixt]

Am 6/15/2010 1:04, schrieb Jay Soffian:
> Subject says it all, but I'll elaborate.
> 
> During the course of testing a merge, I'll sometimes realize there was
> a mistake and I'll amend the merge commit. Sadly this doesn't update
> the rerere cache.

There is

	git rerere forget that/conflicted/file

It definitely works as long as the conflict is still recorded in the
index; I'm not sure if it works after you have staged the updated resolution.

-- Hannes

Re: Amending a merge commit doesn't update the rerere cache

[Jay Soffian]

On Tue, Jun 15, 2010 at 2:23 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> There is
>
>        git rerere forget that/conflicted/file
>
> It definitely works as long as the conflict is still recorded in the
> index; I'm not sure if it works after you have staged the updated resolution.

In fact, I use "rerere forget" as part of a hacked up rerere-train
that I call after I've gotten my merge correct:

---- snip ----
set -- $(git rev-list --parents HEAD -1)
commit=$1; shift
parent1=$1; shift
other_parents="$@"
if test -z "$other_parents"; then
        echo >&2 "HEAD is not a merge commit"
        exit 1
fi

whence=$(git rev-parse --abbrev-ref HEAD)
trap 'git checkout "$whence"' EXIT

git checkout -q "$parent1^0"
if git merge $other_parents; then
        echo "HEAD merges cleanly"
        exit 0
fi

git show -s --pretty=format:"Learning from %h: %s" "$commit"
git rerere forget 2>/dev/null
git checkout -q $commit -- .
git rerere
---- snip ----

I'm still interesting in making commit do the right thing though. In
general, rerere is an underdocumented feature; I guess I'll start
fixing that part first.

(Aside: and the reason I care about rerere being correct is that I
often need to eventually rebase these merges, which is itself a rather
delicate procedure.)

j.