Oh, "unsafe switch" that is off by default will not hurt anybody, and I do
not mind it as a new feature. We are in agreement in that sense.
Perhaps the way forward would be (and this is independent of the issue of
recording removal as a possible form of resolution):
(1) Introduce a new configuration rerere.autoupdate that is off by
default, but when it is on, paths cleanly resolved by rerere will
also be updated in the index (if we have capability to record
removal, this may remove such a path from the index as the result).
(2) The callers of rerere that expects rerere to resolve needs to be
changed to see if the resulting index after rerere is fully merged,
and continue. Currently the callers are "merge", "rebase" and "am",
I think. This step might be a bit more involved than you might
think, as rerere currently happens in the codepath that knows the
caller does _not_ go further than leaving the failed conflict to be
sorted out by the user (rerere is designed as merely a way to help).
Also you _might_ want a separate configuration rerere.autocommit to
control this --- the user (but not you) might be willing to allow
autoupdate but you may still want to eyeball the result.
Independent of the above, we have two potential new features:
* Introduce "git rerere revert paths..." that brings the index and
working tree back to the conflicted state after a previous resolution
is applied, because that resolution is incorrect. The old resolution
cached in rr-cache is also removed.
This however will become much less useful if you allow autoresolution
to be committed automatically, as the caller will move ahead without
giving you a chance to say "oh, that one is bad -- do not proceed".
* Somehow record the fact that the resolution for a particular conflict
signature is to remove the resulting path.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
