Re: understanding merge history

From: Sam Vilain <sam@vilain.net>
Date: Feb 8, 2009, 22:16 UTC
Message-ID: <498F59A6.4000402@vilain.net>
In-Reply-To: <20090204212808.GS3558@iabyn.com>

Dave Mitchell wrote:

Show 32 quoted lines

> Perhaps I was misunderstanding rerere. I assumed it would only replay
> identical resolves on the same branch, rather than being able to cope with
> slightly different resolves on a different branch.
>
> However, after playing with it just now I can't seem to get it to work in
> the initial phase of recording a resolve that has previously taken place.
>
> Given three commits A,B M, where M is a previous merge of A,B:
>
>     A-M
>      /  
>     B
>
> I tried the following:
>
> git checkout A
> git merge B		# replay the initial conflict
> git rerere clear
> git rerere		# record the initial conflict state
>
> git reset --hard M	# simulate the post-resolve state
> git rerere		# and record it
>
>
> But then
>
>     git rerere diff
> and
>     git rerere status
>
> both show nothing, so I'm assuming it didn't manage to capture anything.
>

[cross-posted to the git list so that people will answer who use this command a bit more than myself and to help provide the use case for making the interface better]

I think the problem is that you want to run something like 'git checkout M \*' or 'git read-tree M' instead of 'git reset --hard M'. ie, change the index only and not the HEAD reference. Once this is done then 'git commit' (this will be a dummy commit you'll throw away) or perhaps just 'git rerere' should be enough to update the rerere cache.

But perhaps someone else will have tried this before and knows how to do it..

Sam.