summaryrefslogtreecommitdiff
path: root/Documentation/config/merge.txt
diff options
context:
space:
mode:
authorLibravatar Elijah Newren <newren@gmail.com>2019-04-05 08:00:26 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-04-08 16:02:08 +0900
commit8c8e5bd6eb331d055aa7fa6345f6dcdadd658979 (patch)
tree1bddf4a2616750ba0bb35ac3dcdf80d3ed671552 /Documentation/config/merge.txt
parentmerge-recursive: give callers of handle_content_merge() access to contents (diff)
downloadtgif-8c8e5bd6eb331d055aa7fa6345f6dcdadd658979.tar.xz
merge-recursive: switch directory rename detection default
When all of x/a, x/b, and x/c have moved to z/a, z/b, and z/c on one branch, there is a question about whether x/d added on a different branch should remain at x/d or appear at z/d when the two branches are merged. There are different possible viewpoints here: A) The file was placed at x/d; it's unrelated to the other files in x/ so it doesn't matter that all the files from x/ moved to z/ on one branch; x/d should still remain at x/d. B) x/d is related to the other files in x/, and x/ was renamed to z/; therefore x/d should be moved to z/d. Since there was no ability to detect directory renames prior to git-2.18, users experienced (A) regardless of context. Choice (B) was implemented in git-2.18, with no option to go back to (A), and has been in use since. However, one user reported that the merge results did not match their expectations, making the change of default problematic, especially since there was no notice printed when directory rename detection moved files. Note that there is also a third possibility here: C) There are different answers depending on the context and content that cannot be determined by git, so this is a conflict. Use a higher stage in the index to record the conflict and notify the user of the potential issue instead of silently selecting a resolution for them. Add an option for users to specify their preference for whether to use directory rename detection, and default to (C). Even when directory rename detection is on, add notice messages about files moved into new directories. As a sidenote, x/d did not have to be a new file here; it could have already existed at some other path and been renamed to x/d, with directory rename detection just renaming it again to z/d. Thus, it's not just new files, but also a modification to all rename types (normal renames, rename/add, rename/delete, rename/rename(1to1), rename/rename(1to2), and rename/rename(2to1)). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/config/merge.txt')
-rw-r--r--Documentation/config/merge.txt19
1 files changed, 16 insertions, 3 deletions
diff --git a/Documentation/config/merge.txt b/Documentation/config/merge.txt
index d389c73929..6a313937f8 100644
--- a/Documentation/config/merge.txt
+++ b/Documentation/config/merge.txt
@@ -39,9 +39,22 @@ merge.renameLimit::
is turned off.
merge.renames::
- Whether and how Git detects renames. If set to "false",
- rename detection is disabled. If set to "true", basic rename
- detection is enabled. Defaults to the value of diff.renames.
+ Whether Git detects renames. If set to "false", rename detection
+ is disabled. If set to "true", basic rename detection is enabled.
+ Defaults to the value of diff.renames.
+
+merge.directoryRenames::
+ Whether Git detects directory renames, affecting what happens at
+ merge time to new files added to a directory on one side of
+ history when that directory was renamed on the other side of
+ history. If merge.directoryRenames is set to "false", directory
+ rename detection is disabled, meaning that such new files will be
+ left behind in the old directory. If set to "true", directory
+ rename detection is enabled, meaning that such new files will be
+ moved into the new directory. If set to "conflict", a conflict
+ will be reported for such paths. If merge.renames is false,
+ merge.directoryRenames is ignored and treated as false. Defaults
+ to "conflict".
merge.renormalize::
Tell Git that canonical representation of files in the