]> git.ipfire.org Git - thirdparty/git.git/commit - t/t6423-merge-rename-directories.sh
t6423: note improved ort handling with untracked files
authorElijah Newren <newren@gmail.com>
Mon, 26 Oct 2020 17:01:43 +0000 (17:01 +0000)
committerJunio C Hamano <gitster@pobox.com>
Mon, 26 Oct 2020 19:31:24 +0000 (12:31 -0700)
commitfd15863ec8a90a4c2b4429f5f5de370c8599e700
tree70ec76fb36253b8886c97e98795b74f8161d12c0
parent23bef2e33c3290ae308c2ce37e290a25eb5b97bc
t6423: note improved ort handling with untracked files

Similar to the previous commit, since the "recursive" backend relies on
unpack_trees() to check if unstaged or untracked files would be
overwritten by a merge, and unpack_trees() does not understand renames
-- it has false positives and false negatives.  Once it has run, since
it updates as it goes, merge-recursive then has to handle completing the
merge as best it can despite extra changes in the working copy.
However, this is not just an issue for dirty files, but also for
untracked files because directory renames can cause file contents to
need to be written to a location that was not tracked on either side of
history.

Since the "ort" backend does the complete merge inmemory, and only
updates the index and working copy as a post-processing step, if there
are untracked files in the way it can simply abort the merge much like
checkout does.

Update t6423 to reflect the better merge abilities and expectations for
ort, while still leaving the best-case-as-good-as-recursive-can-do
expectations there for the recursive backend so we retain its stability
until we are ready to deprecate and remove it.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t6423-merge-rename-directories.sh