Thread (1 message) 1 message, 1 author, 2017-08-25

Re: Should rerere auto-update a merge resolution?

flat view

From: Junio C Hamano <hidden>
Date: 2017-08-25 17:08:08

Junio C Hamano [off-list ref] writes:
Junio C Hamano [off-list ref] writes:
quoted
Martin Langhoff [off-list ref] writes:
quoted
 - when I tell it to forget, won't it forget the pre-resolution state?
I do not recall the details of what I did ;-) so I played around a
bit.  Here is what I did:
...
After git rerere forget, I observe (check subdirectories in
.git/rr-cache/ whose timestamps are recent) that postimage gets
removed but preimage and thisimage stay.
Having said that, I suspect that it may be a bug if this procedure
kept the original preimage.  It should either remove it, or update
it to record the state before the ealier resolution was applied
(i.e. make the updated preimage identical to thisimage, so that a
corrected resolution can be taken from the working tree to pair with
it).
I just made a cursory scan of rerere.c again, and it seems we are
doing the right thing.  The details are in rerere_forget_one_path()
where we unlink postimage, we recreate the conflicted state from the
stages in the index and update preimage.

It seems that code gives up if you already declared that you'd take
the previous resolution by adding the result to the index.  It may
probably be a good idea to unmerge such a merged index entry instead
of giving up.  #leftoverbits

So, yes, it will forget both preimage and postimage, and it should
update the preimage with the conflict you got during _this_ merge,
so that the resolution you make _this_ time will become usable as
the corresponding postimage for the next time.


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help