c64432aacd
Testcases 12b and 12c were both slightly weird; they were marked as having a weird resolution, but with the note that even straightforward simple rules can give weird results when the input is bizarre. However, during optimization work for merge-ort, I discovered a significant speedup that is possible if we add one more fairly straightforward rule: we don't bother doing directory rename detection if there are no new files added to the directory on the other side of the history to be affected by the directory rename. This seems like an obvious and straightforward rule, but there was one funny corner case where directory rename detection could affect only existing files: the funny corner case where two directories are renamed into each other on opposite sides of history. In other words, it only results in a different output for testcases 12b and 12c. Since we already thought testcases 12b and 12c were weird anyway, and because the optimization often has a significant effect on common cases (but is entirely prevented if we can't change how 12b and 12c function), let's add the additional rule and tweak how 12b and 12c work. Split both testcases into two (one where we add no new files, and one where the side that doesn't rename a given directory will add files to it), and mark them with the new expectation. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
117 lines
4.9 KiB
Plaintext
117 lines
4.9 KiB
Plaintext
Directory rename detection
|
|
==========================
|
|
|
|
Rename detection logic in diffcore-rename that checks for renames of
|
|
individual files is aggregated and analyzed in merge-recursive for cases
|
|
where combinations of renames indicate that a full directory has been
|
|
renamed.
|
|
|
|
Scope of abilities
|
|
------------------
|
|
|
|
It is perhaps easiest to start with an example:
|
|
|
|
* When all of x/a, x/b and x/c have moved to z/a, z/b and z/c, it is
|
|
likely that x/d added in the meantime would also want to move to z/d by
|
|
taking the hint that the entire directory 'x' moved to 'z'.
|
|
|
|
More interesting possibilities exist, though, such as:
|
|
|
|
* one side of history renames x -> z, and the other renames some file to
|
|
x/e, causing the need for the merge to do a transitive rename so that
|
|
the rename ends up at z/e.
|
|
|
|
* one side of history renames x -> z, but also renames all files within x.
|
|
For example, x/a -> z/alpha, x/b -> z/bravo, etc.
|
|
|
|
* both 'x' and 'y' being merged into a single directory 'z', with a
|
|
directory rename being detected for both x->z and y->z.
|
|
|
|
* not all files in a directory being renamed to the same location;
|
|
i.e. perhaps most the files in 'x' are now found under 'z', but a few
|
|
are found under 'w'.
|
|
|
|
* a directory being renamed, which also contained a subdirectory that was
|
|
renamed to some entirely different location. (And perhaps the inner
|
|
directory itself contained inner directories that were renamed to yet
|
|
other locations).
|
|
|
|
* combinations of the above; see t/t6423-merge-rename-directories.sh for
|
|
various interesting cases.
|
|
|
|
Limitations -- applicability of directory renames
|
|
-------------------------------------------------
|
|
|
|
In order to prevent edge and corner cases resulting in either conflicts
|
|
that cannot be represented in the index or which might be too complex for
|
|
users to try to understand and resolve, a couple basic rules limit when
|
|
directory rename detection applies:
|
|
|
|
1) If a given directory still exists on both sides of a merge, we do
|
|
not consider it to have been renamed.
|
|
|
|
2) If a subset of to-be-renamed files have a file or directory in the
|
|
way (or would be in the way of each other), "turn off" the directory
|
|
rename for those specific sub-paths and report the conflict to the
|
|
user.
|
|
|
|
3) If the other side of history did a directory rename to a path that
|
|
your side of history renamed away, then ignore that particular
|
|
rename from the other side of history for any implicit directory
|
|
renames (but warn the user).
|
|
|
|
Limitations -- detailed rules and testcases
|
|
-------------------------------------------
|
|
|
|
t/t6423-merge-rename-directories.sh contains extensive tests and commentary
|
|
which generate and explore the rules listed above. It also lists a few
|
|
additional rules:
|
|
|
|
a) If renames split a directory into two or more others, the directory
|
|
with the most renames, "wins".
|
|
|
|
b) Only apply implicit directory renames to directories if the other side
|
|
of history is the one doing the renaming.
|
|
|
|
c) Do not perform directory rename detection for directories which had no
|
|
new paths added to them.
|
|
|
|
Limitations -- support in different commands
|
|
--------------------------------------------
|
|
|
|
Directory rename detection is supported by 'merge' and 'cherry-pick'.
|
|
Other git commands which users might be surprised to see limited or no
|
|
directory rename detection support in:
|
|
|
|
* diff
|
|
|
|
Folks have requested in the past that `git diff` detect directory
|
|
renames and somehow simplify its output. It is not clear whether this
|
|
would be desirable or how the output should be simplified, so this was
|
|
simply not implemented. Further, to implement this, directory rename
|
|
detection logic would need to move from merge-recursive to
|
|
diffcore-rename.
|
|
|
|
* am
|
|
|
|
git-am tries to avoid a full three way merge, instead calling
|
|
git-apply. That prevents us from detecting renames at all, which may
|
|
defeat the directory rename detection. There is a fallback, though; if
|
|
the initial git-apply fails and the user has specified the -3 option,
|
|
git-am will fall back to a three way merge. However, git-am lacks the
|
|
necessary information to do a "real" three way merge. Instead, it has
|
|
to use build_fake_ancestor() to get a merge base that is missing files
|
|
whose rename may have been important to detect for directory rename
|
|
detection to function.
|
|
|
|
* rebase
|
|
|
|
Since am-based rebases work by first generating a bunch of patches
|
|
(which no longer record what the original commits were and thus don't
|
|
have the necessary info from which we can find a real merge-base), and
|
|
then calling git-am, this implies that am-based rebases will not always
|
|
successfully detect directory renames either (see the 'am' section
|
|
above). merged-based rebases (rebase -m) and cherry-pick-based rebases
|
|
(rebase -i) are not affected by this shortcoming, and fully support
|
|
directory rename detection.
|