Re: git-rerere: Usage question
Dirk Süsserott <newsletter@dirk.my1.cc> writes:
Show 12 quoted lines
> 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).
