git-rerere: Usage question

git-rerere: Usage question

[Dirk Süsserott]

I recently read the docs for 'git-rerere'. Seems a cool feature.
But I'm not quite sure whether I understood it right. I think
I understood what it does but I didn't understand when to call
it.

Is it true that it's not neccessary to issue that command manually
when I configured "rerere.enabled true"? The docs say that I *can*
call it but it also says that git-merge and git-rebase call it
automatically whenever needed.

Thus it seems to be one of the plumbing tools to me, which
I only call in case of emergency. Am I right?

    Dirk

Re: git-rerere: Usage question

[Junio C Hamano]

Dirk Süsserott <newsletter@dirk.my1.cc> writes:

> I recently read the docs for 'git-rerere'. Seems a cool feature.
> But I'm not quite sure whether I understood it right. I think
> I understood what it does but I didn't understand when to call
> it.
>
> Is it true that it's not neccessary to issue that command manually
> when I configured "rerere.enabled true"? The docs say that I *can*
> call it but it also says that git-merge and git-rebase call it
> automatically whenever needed.
>
> Thus it seems to be one of the plumbing tools to me, which
> I only call in case of emergency. Am I right?

It started as an independent, opt-in feature, that people _could_ use
manually.  In that mode:

 (1) when you see "git merge" stop at a conflict, you say "git rerere",
     expecting one of two benefits:

     (1-a) If the conflict is something you have used rerere on
     previously, this may apply the previous resolution.

     (1-b) Otherwise, the conflict is recorded, so that you can record the
     corresponding resolution after manually resolving it.

 (2) after having to manually resolve the conflict, if you did "git
     rerere" in step (1), you can say "git rerere" again to record it.

These days, rerere is pretty much automatic in that rerere is called
automatically from places that generate conflicts (e.g. "git merge") for
purpose of (1), and from places that the user tells git that the conflicts
are now resolved (e.g. "git commit") for purpose of (2).

So it is not even for "emergency" anymore.

The only time you still might want to call it yourself is when you are not
comfortable with the conflict resolution you just did (iow, if it later
turns out to be a bad resolution, you may regret recording that incorrect
resolution).  In such a case, you would say "git rerere clear" before
committing the result (in which time, "rerere" automatically try to record
but because of earlier "rerere clear" it does not find anything to
record).

Re: git-rerere: Usage question

[Mike Hommey]

On Fri, May 23, 2008 at 05:02:11PM -0700, Junio C Hamano wrote:
> These days, rerere is pretty much automatic in that rerere is called
> automatically from places that generate conflicts (e.g. "git merge") for
> purpose of (1), and from places that the user tells git that the conflicts
> are now resolved (e.g. "git commit") for purpose of (2).

Note that it is not totally automatic for most people because the
default is to enable only if the .git/rr_cache directory exists, and
neither git init nor git clone create this directory.

You still have to set rerere.enabled yourself.

Mike

Re: git-rerere: Usage question

[Dirk Süsserott]

Mike Hommey schrieb:
> On Fri, May 23, 2008 at 05:02:11PM -0700, Junio C Hamano wrote:
>   
>> These days, rerere is pretty much automatic in that rerere is called
>> automatically from places that generate conflicts (e.g. "git merge") for
>> purpose of (1), and from places that the user tells git that the conflicts
>> are now resolved (e.g. "git commit") for purpose of (2).
>>     
>
> Note that it is not totally automatic for most people because the
> default is to enable only if the .git/rr_cache directory exists, and
> neither git init nor git clone create this directory.
>   
git-gc does -- at least if rerere.enabled is set.
Thanks for the pointer that this directory must exist.
Probably it gets auto-created when needed?
I didn't check that out coz I currently have nothing
to merge with :-(
A simple no-op "git pull" (Already up-to-date)
did *not* create the directory, but git-gc did.

    Dirk