git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Theodore Tso <tytso@mit.edu>, git@vger.kernel.org
Subject: Re: git-rerere observations and feature suggestions
Date: Mon, 16 Jun 2008 14:37:56 -0700	[thread overview]
Message-ID: <7viqw99i2z.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20080616204630.GA552@elte.hu> (Ingo Molnar's message of "Mon, 16 Jun 2008 22:46:30 +0200")

Ingo Molnar <mingo@elte.hu> writes:

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

  reply	other threads:[~2008-06-16 21:39 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-16 11:01 git-rerere observations and feature suggestions Ingo Molnar
2008-06-16 11:09 ` Mike Hommey
2008-06-16 15:48   ` Pierre Habouzit
2008-06-16 15:57     ` Pierre Habouzit
2008-06-16 16:18       ` Sverre Rabbelier
2008-06-17  7:37         ` Karl Hasselström
2008-06-16 11:26 ` David Kastrup
2008-06-16 11:27 ` Theodore Tso
2008-06-16 12:38   ` David Kastrup
2008-06-16 19:52   ` Ingo Molnar
2008-06-16 20:25     ` Junio C Hamano
2008-06-16 20:46       ` Ingo Molnar
2008-06-16 21:37         ` Junio C Hamano [this message]
2008-06-16 18:46 ` Junio C Hamano
2008-06-16 19:09   ` Ingo Molnar
2008-06-16 20:50     ` Junio C Hamano
2008-06-22  9:47       ` [PATCH 1/5] rerere: rerere_created_at() and has_resolution() abstraction Junio C Hamano
2008-06-22  9:47       ` [PATCH 2/5] git-rerere: detect unparsable conflicts Junio C Hamano
2008-06-22  9:47       ` [PATCH 3/5] rerere: remove dubious "tail_optimization" Junio C Hamano
2008-06-22  9:48       ` [PATCH 4/5] t4200: fix rerere test Junio C Hamano
2008-06-22  9:48       ` [PATCH 5/5] rerere.autoupdate Junio C Hamano
2008-06-18 10:57     ` git-rerere observations and feature suggestions Ingo Molnar
2008-06-18 11:29       ` Miklos Vajna
2008-06-18 18:43         ` Ingo Molnar
2008-06-18 19:53           ` Miklos Vajna
2008-06-18 11:36       ` Ingo Molnar
2008-06-18 22:01       ` Jakub Narebski
2008-06-18 22:38         ` Miklos Vajna
2008-06-19  7:23           ` Karl Hasselström
2008-06-19  7:29             ` Miklos Vajna
2008-06-19  7:30             ` Junio C Hamano
2008-06-19  8:21               ` Karl Hasselström
2008-06-19  8:33                 ` Miklos Vajna
2008-06-19  9:19                   ` Karl Hasselström
2008-06-19 10:06                     ` Miklos Vajna
2008-06-19 10:35                       ` Karl Hasselström
2008-06-16 19:10   ` Junio C Hamano
2008-06-16 19:44     ` Ingo Molnar
2008-06-23  9:49   ` Ingo Molnar
2008-06-23 14:19     ` Peter Zijlstra
2008-06-23 14:26       ` Peter Zijlstra
2008-06-23 15:12     ` Jeff King
2008-06-23 15:22       ` Ingo Molnar
2008-06-16 20:11 ` Jakub Narebski
2008-06-17 10:24 ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7viqw99i2z.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).