Re: git-rerere observations and feature suggestions

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 16, 2008, 21:37 UTC
Message-ID: <7viqw99i2z.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080616204630.GA552@elte.hu>

Ingo Molnar <mingo@elte.hu> writes:

Show 14 quoted lines

> * Junio C Hamano <gitster@pobox.com> wrote:
>
>> Ingo Molnar <mingo@elte.hu> writes:
>> 
>> > right now that is simply not possible technically - it's even very 
>> > hard to share a .git/rr-cache with a co-maintainer whom i can trust 
>> > with my index file. (which is an otherwise unsafe private binary 
>> > cache that i'd not put into a public repository as it could in 
>> > theory contain lots of unrelated data and is not endian-safe, etc.)
>> 
>> Where did you get the idea that .git/index is involved in any way, I 
>> wonder...
>
> so it's only the rr-cache metadata that is involved?

The binary part of the index should be in network byte order and endian safe. But it is not necessary to share the index. Well, if you think about it, it would be mighty silly if index had any long term effect on the operation of rerere, which is all about "I've done many conflict resolutions in the past. My work tree state (including the index) came back to a state similar to the conflicted state I saw some time ago. Let's reuse the previous resolution if we can." You might have switched branches, ran "reset --hard" and did 47 thousands different things to your index since you resolved the conflict you are about to re-resolve ;-).

The replay and conflict recoding codepath of rerere goes like this:

 * read the index, list the paths that have conflicts;

 * inspect the conflicted blob to compute the conflict signature $sig and
   store the sig and path in MERGE_RR;

 * look into rr-cache/$sig; does it have already a conflict resolution
   recorded?

   - If so, modify the file in the working tree the same way to bring
     rr-cache/$sig/preimage to rr-cache/$sig/postimage by 3-way merge.

   - if not, record the file in the working tree as rr-cache/$sig/preimage

The resolution recording codepath goes like:

 * see if any paths listed in MERGE_RR is resolved in the index;

 * look into rr-cache/$sig for such resolved path.  Does it already record
   a resolution?

   - If not, we have a new resolution we can use.  Record it as
     rr-cache/$sig/postimage for later use.

So rerere _does_ look at the index to decide what entries in rr-cache are relevant and applicable. But other than that, it is not used. I do not think there is no reason copy index to be able to reuse rr-cache.