Re: Should rerere auto-update a merge resolution?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Martin Langhoff <martin.langhoff@xxxxxxxxx> writes:
>
>>  - 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).

As you may be able to see, "rerere forget" is much less used, hence
much less exposed to end-user needs to gain both feature and
usability polish than other parts of "rerere".  I'd expect there
would be many cases where an extra cleverness can be used without
making the result less robust, and it would be a good thing to see
if we can improve them.  We must avoid the cleverness leading us to
a "works most of the time" machinery whose operation cannot be
trusted, though.

The way the current machinery works is

 * "rerere" sees an unmerged index entry.  It computes the conflict id
   to look into its database, finds a <pre,post> image pair, and
   does a three-way merge to update the working tree file (with
   conflict markers) with pre->post change (i.e. previous resolution).

and that's it.  We may be able to make "updating the resolution"
easier, perhaps like so:

 * The end user edits working tree file further to correct the
   mistake in the earlier resolution that was applied.

 * The end user says "rerere update <path>", which internally does
   the equivalent of "checkout -m <path>" to unmerge and then
   computes the preimage for this round by redoing the original
   merge, write out the preimage and take the working tree file as
   the postimage

We might even be able to do a bit more in the "normal application"
codepath to make it record the result of the three-way merge,
perhaps in an index extension.  Then "rerere update <path>" may not
even be needed---at strategic places in the workflow (e.g. when the
user adds the path to the index), we can check if the contents is
different from what rerere wrote out as the resolution and if they
differ, do the "rerere update <path>" automatically.

But we may be taking the extra cleverness a bit too close to a
danger zone by trying to automate too much without thinking the
ramification through, so I'd stop speculation at this point.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux