]> git.ipfire.org Git - thirdparty/git.git/commit
merge-ort: add implementation of normal rename handling
authorElijah Newren <newren@gmail.com>
Tue, 15 Dec 2020 18:28:05 +0000 (18:28 +0000)
committerJunio C Hamano <gitster@pobox.com>
Wed, 16 Dec 2020 01:18:32 +0000 (17:18 -0800)
commitf1665e69188f54c941f9bf10ed388a72a91cc2a1
treed02f1a13b37322226e5089be59359769d7473e0a
parent35e47e3514b5129e6075a67fa9f4659da2f1a1a1
merge-ort: add implementation of normal rename handling

Implement handling of normal renames.  This code replaces the following
from merge-recurisve.c:

  * the code relevant to RENAME_NORMAL in process_renames()
  * the RENAME_NORMAL case of process_entry()

Also, there is some shared code from merge-recursive.c for multiple
different rename cases which we will no longer need for this case (or
other rename cases):

  * handle_rename_normal()
  * setup_rename_conflict_info()

The consolidation of four separate codepaths into one is made possible
by a change in design: process_renames() tweaks the conflict_info
entries within opt->priv->paths such that process_entry() can then
handle all the non-rename conflict types (directory/file, modify/delete,
etc.) orthogonally.  This means we're much less likely to miss special
implementation of some kind of combination of conflict types (see
commits brought in by 66c62eaec6 ("Merge branch 'en/merge-tests'",
2020-11-18), especially commit ef52778708 ("merge tests: expect improved
directory/file conflict handling in ort", 2020-10-26) for more details).
That, together with letting worktree/index updating be handled
orthogonally in the merge_switch_to_result() function, dramatically
simplifies the code for various special rename cases.

(To be fair, the code for handling normal renames wasn't all that
complicated beforehand, but it's still much simpler now.)

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-ort.c