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.
