]> git.ipfire.org Git - thirdparty/git.git/commit
Reintegrate: cope with delete-modify conflicts
authorJunio C Hamano <gitster@pobox.com>
Mon, 11 Dec 2023 20:40:09 +0000 (12:40 -0800)
committerJunio C Hamano <gitster@pobox.com>
Mon, 11 Dec 2023 20:40:09 +0000 (12:40 -0800)
commitaaf962df4a807886abb21c1a95ba6652a64943eb
tree5d305c84f96d87046e6f7050c14a6f72a1ebde68
parenta332d1db1da2359180ff9228e7223916175c6c20
Reintegrate: cope with delete-modify conflicts

A more proper solution is probably to teach "rerere" to remember
what modification (probably indexed via a patch ID for flexibility,
but either the pre- or post-image blob ID without such flexibility
is probably good enough) was deemed "uninteresting" to resolve in
favor of deletion and reapply it when we see another delete-modify
conflict with the same modification, but for now, treat all
delete-modify conflict to be with uninteresting modification.

The way the Reintegrate machinery is used makes it somewhat safer
than it looks---the initial attempt to merge (and come up with a
merge-fix if needed) will always be done using "git merge" and the
resulting commit is manually examined (if only to see if there is a
need for a further merge-fix) before redo-foo script is written out
of the resulting history.  We'll need to deal with a case where a
modifying side need to be kept over the deleting side if/when it
arises, but so far I haven't seen such a case in real life.
Reintegrate