merge-ort: add implementation of type-changed rename handling
Implement cases where renames are involved in type changes (i.e. the side of history that didn't rename the file changed its type from a regular file to a symlink or submodule). There was some code to handle this in merge-recursive but only in the special case when the renamed file had no content changes. The code here works differently -- it knows process_entry() can handle mode conflicts, so it does a few minimal tweaks to ensure process_entry() can just finish the job as needed. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Elijah Newren committed
Dec 15, 2020 at 18:28 UTC
6fcccbd75556d1dcc80493f6eb51109f53a5dc83
1 file changed
+32
-3
merge-ort.c
+32
-3
@@ -777,8 +777,33 @@ static int process_renames(struct merge_options *opt,
777
(S_ISREG(oldinfo->stages[other_source_index].mode) !=
778
S_ISREG(newinfo->stages[target_index].mode));
779
if (type_changed && collision) {
780
- /* special handling so later blocks can handle this */
781
- die("Not yet implemented");
780
+ /*
781
+ * special handling so later blocks can handle this...
782
+ *
783
+ * if type_changed && collision are both true, then this
784
+ * was really a double rename, but one side wasn't
785
+ * detected due to lack of break detection. I.e.
786
+ * something like
787
+ * orig: has normal file 'foo'
788
+ * side1: renames 'foo' to 'bar', adds 'foo' symlink
789
+ * side2: renames 'foo' to 'bar'
790
+ * In this case, the foo->bar rename on side1 won't be
791
+ * detected because the new symlink named 'foo' is
792
+ * there and we don't do break detection. But we detect
793
+ * this here because we don't want to merge the content
794
+ * of the foo symlink with the foo->bar file, so we
795
+ * have some logic to handle this special case. The
796
+ * easiest way to do that is make 'bar' on side1 not
797
+ * be considered a colliding file but the other part
798
+ * of a normal rename. If the file is very different,
799
+ * well we're going to get content merge conflicts
800
+ * anyway so it doesn't hurt. And if the colliding
801
+ * file also has a different type, that'll be handled
802
+ * by the content merge logic in process_entry() too.
803
+ *
804
+ * See also t6430, 'rename vs. rename/symlink'
805
+ */
806
+ collision = 0;
807
}
808
if (source_deleted) {
809
if (target_index == 1) {
@@ -859,7 +884,11 @@ static int process_renames(struct merge_options *opt,
884
newinfo->pathnames[0] = oldpath;
885
if (type_changed) {
886
/* rename vs. typechange */
862
- die("Not yet implemented");
887
+ /* Mark the original as resolved by removal */
888
+ memcpy(&oldinfo->stages[0].oid, &null_oid,
889
+ sizeof(oldinfo->stages[0].oid));
890
+ oldinfo->stages[0].mode = 0;
891
+ oldinfo->filemask &= 0x06;
892
} else if (source_deleted) {
893
/* rename/delete */
894
newinfo->path_conflict = 1;