| blob | 6c40c61c4728d9224006768599d7bf2ded744bb1 |
1 /*
2 * Recursive Merge algorithm stolen from git-merge-recursive.py by
3 * Fredrik Kuivinen.
4 * The thieves were Alex Riesen and Johannes Schindelin, in June/July 2006
5 */
35 };
41 {
48 else
50 }
53 {
55 }
59 {
67 }
73 {
78 }
81 {
83 }
87 {
93 }
97 {
103 }
109 {
111 }
114 {
116 }
119 {
123 }
124 }
127 {
135 }
144 }
147 }
152 {
159 subtree_shift);
160 }
164 }
169 {
176 }
178 /*
179 * Since we use get_tree_entry(), which does not put the read object into
180 * the object pool, we cannot rely on a == b.
181 */
183 {
187 }
191 RENAME_VIA_DIR,
192 RENAME_ADD,
193 RENAME_DELETE,
194 RENAME_ONE_FILE_TO_ONE,
195 RENAME_ONE_FILE_TO_TWO,
196 RENAME_TWO_FILES_TO_ONE
197 };
209 };
211 /*
212 * Since we want to write the index eventually, we cannot reuse the index
213 * for these (temporary) data.
214 */
222 };
234 {
238 /*
239 * When we have two renames involved, it's easiest to get the
240 * correct things into stage 2 and 3, and to make sure that the
241 * content merge puts HEAD before the other branch if we just
242 * ensure that branch1 == o->branch1. So, simply flip arguments
243 * around if we don't have that.
244 */
250 o,
253 }
270 }
272 /*
273 * For each rename, there could have been
274 * modifications on the side of history where that
275 * file was not renamed.
276 */
284 }
292 }
293 }
296 {
298 }
302 {
317 }
320 {
329 DEFAULT_ABBREV);
340 }
341 }
343 }
348 {
367 }
369 }
372 {
375 }
381 {
389 else
406 /*
407 * Update o->repo->index to match the new results, AFTER saving a copy
408 * in o->orig_index. Update src_index to point to the saved copy.
409 * (verify_uptodate() checks src_index, and the original index is
410 * the one that had the necessary modification timestamps.)
411 */
417 }
420 {
423 }
426 {
438 }
440 }
449 }
454 }
459 {
472 }
475 {
480 }
486 {
493 }
495 }
497 /*
498 * Returns an index_entry instance which doesn't have to correspond to
499 * a real cache entry in Git's index.
500 */
504 {
516 }
518 /*
519 * Create a dictionary mapping file names to stage_data objects. The
520 * dictionary contains one entry for every path with a non-zero stage entry.
521 */
523 {
540 }
544 }
547 }
550 {
553 /*
554 * Here we only care that entries for D/F conflicts are
555 * adjacent, in particular with the file of the D/F conflict
556 * appearing before files below the corresponding directory.
557 * The order of the rest of the list is irrelevant for us.
558 *
559 * To achieve this, we sort with df_name_compare and provide
560 * the mode S_IFDIR so that D/F conflicts will sort correctly.
561 * We use the mode S_IFDIR for everything else for simplicity,
562 * since in other cases any changes in their order due to
563 * sorting cause no problems for us.
564 */
567 /*
568 * Now that 'foo' and 'foo/bar' compare equal, we have to make sure
569 * that 'foo' comes before 'foo/bar'.
570 */
574 }
578 {
579 /* If there is a D/F conflict and the file for such a conflict
580 * currently exists in the working tree, we want to allow it to be
581 * removed to make room for the corresponding directory if needed.
582 * The files underneath the directories of such D/F conflicts will
583 * be processed before the corresponding file involved in the D/F
584 * conflict. If the D/F directory ends up being removed by the
585 * merge, then we won't have to touch the D/F file. If the D/F
586 * directory needs to be written to the working copy, then the D/F
587 * file will simply be removed (in make_room_for_path()) to make
588 * room for the necessary paths. Note that if both the directory
589 * and the file need to be present, then the D/F file will be
590 * reinstated with a new unique name at the time it is processed.
591 */
597 /*
598 * If we're merging merge-bases, we don't want to bother with
599 * any working directory changes.
600 */
604 /* Ensure D/F conflicts are adjacent in the entries list. */
609 }
619 /*
620 * Check if last_file & path correspond to a D/F conflict;
621 * i.e. whether path is last_file+'/'+<something>.
622 * If so, record that it's okay to remove last_file to make
623 * room for path and friends if needed.
624 */
630 }
632 /*
633 * Determine whether path could exist as a file in the
634 * working directory as a possible D/F conflict. This
635 * will only occur when it exists in stage 2 as a
636 * file.
637 */
643 }
644 }
646 }
650 /*
651 * Purpose of src_entry and dst_entry:
652 *
653 * If 'before' is renamed to 'after' then src_entry will contain
654 * the versions of 'before' from the merge_base, HEAD, and MERGE in
655 * stages 1, 2, and 3; dst_entry will contain the respective
656 * versions of 'after' in corresponding locations. Thus, we have a
657 * total of six modes and oids, though some will be null. (Stage 0
658 * is ignored; we're interested in handling conflicts.)
659 *
660 * Since we don't turn on break-rewrites by default, neither
661 * src_entry nor dst_entry can have all three of their stages have
662 * non-null oids, meaning at most four of the six will be non-null.
663 * Also, since this is a rename, both src_entry and dst_entry will
664 * have at least one non-null oid, meaning at least two will be
665 * non-null. Of the six oids, a typical rename will have three be
666 * non-null. Only two implies a rename/delete, and four implies a
667 * rename/add.
668 */
673 };
679 {
681 /*
682 * NOTE: It is usually a bad idea to call update_stages on a path
683 * before calling update_file on that same path, since it can
684 * sometimes lead to spurious "refusing to lose untracked file..."
685 * messages from update_file (via make_room_for path via
686 * would_lose_untracked). Instead, reverse the order of the calls
687 * (executing update_file first and then update_stages).
688 */
704 }
710 {
718 }
722 {
729 }
734 ignore_case);
737 }
740 }
742 }
744 /* add a string to a strbuf, but converting "/" to "_" */
746 {
752 }
755 {
770 }
776 }
778 /**
779 * Check whether a directory in the index is in the way of an incoming
780 * file. Return 1 if so. If check_working_copy is non-zero, also
781 * check the working directory. If empty_ok is non-zero, also return
782 * 0 in the case where the working-tree dir exists but is empty.
783 */
786 {
802 }
807 }
809 /*
810 * Returns whether path was tracked in the index before the merge started,
811 * and its oid and mode match the specified values
812 */
815 {
820 /* we were not tracking this path before the merge */
823 /* See if the file we were tracking before matches */
826 }
828 /*
829 * Returns whether path was tracked in the index before the merge started
830 */
832 {
836 /* we were tracking this path before the merge */
840 }
843 {
846 /*
847 * This may look like it can be simplified to:
848 * return !was_tracked(o, path) && file_exists(path)
849 * but it can't. This function needs to know whether path was in
850 * the working tree due to EITHER having been tracked in the index
851 * before the merge OR having been put into the working copy and
852 * index by unpack_trees(). Due to that either-or requirement, we
853 * check the current index instead of the original one.
854 *
855 * Note that we do not need to worry about merge-recursive itself
856 * updating the index after unpack_trees() and before calling this
857 * function, because we strictly require all code paths in
858 * merge-recursive to update the working tree first and the index
859 * second. Doing otherwise would break
860 * update_file()/would_lose_untracked(); see every comment in this
861 * file which mentions "update_stages".
862 */
869 /*
870 * If stage #0, it is definitely tracked.
871 * If it has stage #2 then it was tracked
872 * before this merge started. All other
873 * cases the path was not tracked.
874 */
879 }
880 pos++;
881 }
883 }
886 {
897 }
900 {
904 /* Unlink any D/F conflict files that are in the way */
914 df_path);
919 }
920 }
922 /* Make sure leading directories are created */
926 /* something else exists */
929 }
931 /*
932 * Do not unlink a file in the work tree if we are not
933 * tracking it.
934 */
937 path);
939 /* Successful unlink is good.. */
942 /* .. and so is no existing file */
945 /* .. but not some other error (who really cares what?) */
947 }
955 {
967 /*
968 * We may later decide to recursively descend into
969 * the submodule directory and update its index
970 * and/or work tree, but we do not do that now.
971 */
974 }
982 }
989 }
990 }
995 }
1000 else
1007 }
1022 free_buf:
1024 }
1025 update_index:
1028 ADD_CACHE_OK_TO_ADD))
1031 }
1038 {
1040 }
1042 /* Low level file merging, update and removal */
1049 };
1059 {
1083 }
1084 }
1097 }
1114 }
1119 {
1134 /* get all revisions that merge commit a */
1139 /* FIXME: can't handle linked worktrees in submodules yet */
1143 /* save all revisions from the above list that contain b */
1150 }
1153 /* Now we've got all merges that contain a and b. Prune all
1154 * merges that contain another found merge and save them in
1155 * result.
1156 */
1166 }
1167 }
1171 }
1175 }
1178 {
1185 }
1191 {
1199 /* store a in result in case we fail */
1202 /* we can not handle deletion conflicts */
1213 }
1220 }
1222 /* check whether both changes are forward */
1227 }
1229 /* Case #1: a is contained in b or vice versa */
1237 else
1241 }
1249 else
1253 }
1255 /*
1256 * Case #2: There are one or more merges that contain a and b in
1257 * the submodule. If there is only one, then present it as a
1258 * suggestion to the user, but leave it marked unmerged so the
1259 * user needs to confirm the resolution.
1260 */
1262 /* Skip the search if makes no sense to the calling context. */
1266 /* find commit which merges them */
1279 "If this is correct simply add it to the index "
1291 }
1295 }
1306 {
1308 /*
1309 * It's weird getting a reverse merge with HEAD on the bottom
1310 * side of the conflict markers and the other branch on the
1311 * top. Fix that.
1312 */
1314 filename,
1317 }
1330 }
1335 /*
1336 * Merge modes
1337 */
1345 }
1346 }
1353 mmbuffer_t result_buf;
1358 extra_marker_size);
1392 }
1395 }
1401 }
1406 {
1407 /*
1408 * Handle file adds that need to be renamed due to directory rename
1409 * detection. This differs from handle_rename_normal, because
1410 * there is no content merge to do; just move the file into the
1411 * desired final location.
1412 */
1421 /*
1422 * Write the file in worktree at alt_path, but not in the
1423 * index. Instead, write to dest->path for the index but
1424 * only at the higher appropriate stage.
1425 */
1432 }
1434 /* Update dest->path both in index and in worktree */
1438 }
1448 {
1456 }
1459 /*
1460 * We cannot arbitrarily accept either a_sha or b_sha as
1461 * correct; since there is no true "middle point" between
1462 * them, simply reuse the base version for virtual merge base.
1463 */
1468 /*
1469 * Despite the four nearly duplicate messages and argument
1470 * lists below and the ugliness of the nested if-statements,
1471 * having complete messages makes the job easier for
1472 * translators.
1473 *
1474 * The slight variance among the cases is due to the fact
1475 * that:
1476 * 1) directory/file conflicts (in effect if
1477 * !alt_path) could cause us to need to write the
1478 * file to a different path.
1479 * 2) renames (in effect if !old_path) could mean that
1480 * there are two names for the path that the user
1481 * may know the file by.
1482 */
1494 }
1506 }
1507 }
1508 /*
1509 * No need to call update_file() on path when change_branch ==
1510 * o->branch1 && !alt_path, since that would needlessly touch
1511 * path. We could call update_file_flags() with update_cache=0
1512 * and update_wd=0, but that's a no-op.
1513 */
1516 }
1520 }
1526 {
1541 else
1545 }
1550 {
1558 }
1569 {
1575 /*
1576 * It's easiest to get the correct things into stage 2 and 3, and
1577 * to make sure that the content merge puts HEAD before the other
1578 * branch if we just ensure that branch1 == o->branch1. So, simply
1579 * flip arguments around if we don't have that.
1580 */
1587 }
1589 /*
1590 * In the recursive case, we just opt to undo renames
1591 */
1593 /* Put first file (a_oid, a_mode) in its original spot */
1600 }
1602 /* Put second file (b_oid, b_mode) in its original spot */
1609 }
1611 /* Don't leave something at collision path if unrenaming both */
1616 }
1618 /* Remove rename sources if rename/add or rename/rename(2to1) */
1626 /*
1627 * Remove the collision path, if it wouldn't cause dirty contents
1628 * or an untracked file to get lost. We'll either overwrite with
1629 * merged contents, or just write out to differently named files.
1630 */
1633 collide_path);
1636 /*
1637 * Only way we get here is if both renames were from
1638 * a directory rename AND user had an untracked file
1639 * at the location where both files end up after the
1640 * two directory renames. See testcase 10d of t6043.
1641 */
1644 collide_path);
1647 /*
1648 * FIXME: It's possible that the two files are identical
1649 * and that the current working copy happens to match, in
1650 * which case we are unnecessarily touching the working
1651 * tree file. It's not a likely enough scenario that I
1652 * want to code up the checks for it and a better fix is
1653 * available if we restructure how unpack_trees() and
1654 * merge-recursive interoperate anyway, so punting for
1655 * now...
1656 */
1658 }
1660 /* Store things in diff_filespecs for functions that need it */
1683 /*
1684 * FIXME: If both a & b both started with conflicts (only possible
1685 * if they came from a rename/rename(2to1)), but had IDENTICAL
1686 * contents including those conflicts, then in the next line we claim
1687 * it was clean. If someone cares about this case, we should have the
1688 * caller notify us if we started with conflicts.
1689 */
1691 }
1695 {
1696 /* a was renamed to c, and a separate c was added. */
1723 }
1729 {
1741 }
1744 }
1748 {
1749 /* One file was renamed in both branches, but to different names. */
1774 /*
1775 * FIXME: For rename/add-source conflicts (if we could detect
1776 * such), this is wrong. We should instead find a unique
1777 * pathname and then either rename the add-source file to that
1778 * unique path, or use that unique path instead of src here.
1779 */
1783 /*
1784 * Above, we put the merged content at the merge-base's
1785 * path. Now we usually need to delete both a->path and
1786 * b->path. However, the rename on each side of the merge
1787 * could also be involved in a rename/add conflict. In
1788 * such cases, we should keep the added file around,
1789 * resolving the conflict at that path in its favor.
1790 */
1795 }
1796 else
1802 }
1803 else
1806 /*
1807 * For each destination path, we need to see if there is a
1808 * rename/add collision. If not, we can write the file out
1809 * to the specified location.
1810 */
1828 }
1847 }
1848 }
1851 }
1855 {
1856 /* Two files, a & b, were renamed to the same thing, c. */
1868 "Rename %s->%s in %s. "
1889 }
1891 /*
1892 * Get the diff_filepairs changed between o_tree and tree.
1893 */
1897 {
1905 /*
1906 * We do not have logic to handle the detection of copies. In
1907 * fact, it may not even make sense to add such logic: would we
1908 * really want a change to a base file to be propagated through
1909 * multiple other files by a merge?
1910 */
1933 }
1936 {
1942 }
1944 /*
1945 * Return a new string that replaces the beginning portion (which matches
1946 * entry->dir), with entry->new_dir. In perl-speak:
1947 * new_path_name = (old_path =~ s/entry->dir/entry->new_dir/);
1948 * NOTE:
1949 * Caller must ensure that old_path starts with entry->dir + '/'.
1950 */
1953 {
1967 }
1971 {
1978 /*
1979 * For
1980 * "a/b/c/d/e/foo.c" -> "a/b/some/thing/else/e/foo.c"
1981 * the "e/foo.c" part is the same, we just want to know that
1982 * "a/b/c/d" was renamed to "a/b/some/thing/else"
1983 * so, for this example, this function returns "a/b/c/d" in
1984 * *old_dir and "a/b/some/thing/else" in *new_dir.
1985 *
1986 * Also, if the basename of the file changed, we don't care. We
1987 * want to know which portion of the directory, if any, changed.
1988 */
1998 /*
1999 * We've found the first non-matching character in the directory
2000 * paths. That means the current directory we were comparing
2001 * represents the rename. Move end_of_old and end_of_new back
2002 * to the full directory name.
2003 */
2005 end_of_old++;
2007 end_of_new++;
2011 /*
2012 * It may have been the case that old_path and new_path were the same
2013 * directory all along. Don't claim a rename if they're the same.
2014 */
2021 }
2022 }
2026 {
2033 }
2035 }
2037 /*
2038 * See if there is a directory rename for path, and if there are any file
2039 * level conflicts for the renamed location. If there is a rename and
2040 * there are no conflicts, return the new name. Otherwise, return NULL.
2041 */
2047 {
2053 /*
2054 * entry has the mapping of old directory name to new directory name
2055 * that we want to apply to path.
2056 */
2060 /* This should only happen when entry->non_unique_new_dir set */
2064 "Unclear where to place %s because directory "
2065 "%s was renamed to multiple other directories, "
2066 "with no destination getting a majority of the "
2071 }
2073 /*
2074 * The caller needs to have ensured that it has pre-populated
2075 * collisions with all paths that map to new_path. Do a quick check
2076 * to ensure that's the case.
2077 */
2082 /*
2083 * Check for one-sided add/add/.../add conflicts, i.e.
2084 * where implicit renames from the other side doing
2085 * directory rename(s) can affect this side of history
2086 * to put multiple paths into the same location. Warn
2087 * and bail on directory renames for such paths.
2088 */
2096 "file/dir at %s in the way of implicit "
2097 "directory rename(s) putting the following "
2106 "more than one path to %s; implicit directory "
2110 }
2112 /* Free memory we no longer need */
2117 }
2120 }
2122 /*
2123 * There are a couple things we want to do at the directory level:
2124 * 1. Check for both sides renaming to the same thing, in order to avoid
2125 * implicit renaming of files that should be left in place. (See
2126 * testcase 6b in t6043 for details.)
2127 * 2. Prune directory renames if there are still files left in the
2128 * the original directory. These represent a partial directory rename,
2129 * i.e. a rename where only some of the files within the directory
2130 * were renamed elsewhere. (Technically, this could be done earlier
2131 * in get_directory_renames(), except that would prevent us from
2132 * doing the previous check and thus failing testcase 6b.)
2133 * 3. Check for rename/rename(1to2) conflicts (at the directory level).
2134 * In the future, we could potentially record this info as well and
2135 * omit reporting rename/rename(1to2) conflicts for each path within
2136 * the affected directories, thus cleaning up the merge output.
2137 * NOTE: We do NOT check for rename/rename(2to1) conflicts at the
2138 * directory level, because merging directories is fine. If it
2139 * causes conflicts for files within those merged directories, then
2140 * that should be detected at the individual path level.
2141 */
2147 {
2162 /* 1. Renamed identically; remove it from both sides */
2170 /* 2. This wasn't a directory rename after all */
2174 }
2175 }
2184 /* 2. This wasn't a directory rename after all */
2190 /* 3. rename/rename(1to2) */
2191 /*
2192 * We can assume it's not rename/rename(1to1) because
2193 * that was case (1), already checked above. So we
2194 * know that head_ent->new_dir and merge_ent->new_dir
2195 * are different strings.
2196 */
2198 "Rename directory %s->%s in %s. "
2208 }
2209 }
2213 }
2216 {
2222 /*
2223 * Typically, we think of a directory rename as all files from a
2224 * certain directory being moved to a target directory. However,
2225 * what if someone first moved two files from the original
2226 * directory in one commit, and then renamed the directory
2227 * somewhere else in a later commit? At merge time, we just know
2228 * that files from the original directory went to two different
2229 * places, and that the bulk of them ended up in the same place.
2230 * We want each directory rename to represent where the bulk of the
2231 * files from that directory end up; this function exists to find
2232 * where the bulk of the files went.
2233 *
2234 * The first loop below simply iterates through the list of file
2235 * renames, finding out how often each directory rename pair
2236 * possibility occurs.
2237 */
2246 /* File not part of directory rename if it wasn't renamed */
2253 /* Directory didn't change at all; ignore this one. */
2263 }
2267 new_dir);
2271 }
2274 }
2276 /*
2277 * For each directory with files moved out of it, we find out which
2278 * target directory received the most files so we can declare it to
2279 * be the "winning" target location for the directory rename. This
2280 * winner gets recorded in new_dir. If there is no winner
2281 * (multiple target directories received the same number of files),
2282 * we set non_unique_new_dir. Once we've determined the winner (or
2283 * that there is no winner), we no longer need possible_new_dirs.
2284 */
2299 }
2300 }
2306 }
2307 /*
2308 * The relevant directory sub-portion of the original full
2309 * filepaths were xstrndup'ed before inserting into
2310 * possible_new_dirs, and instead of manually iterating the
2311 * list and free'ing each, just lie and tell
2312 * possible_new_dirs that it did the strdup'ing so that it
2313 * will free them for us.
2314 */
2317 }
2320 }
2324 {
2334 }
2337 }
2342 {
2345 /*
2346 * Multiple files can be mapped to the same path due to directory
2347 * renames done by the other side of history. Since that other
2348 * side of history could have merged multiple directories into one,
2349 * if our side of history added the same file basename to each of
2350 * those directories, then all N of them would get implicitly
2351 * renamed by the directory rename detection into the same path,
2352 * and we'd get an add/add/.../add conflict, and all those adds
2353 * from *this* side of history. This is not representable in the
2354 * index, and users aren't going to easily be able to make sense of
2355 * it. So we need to provide a good warning about what's
2356 * happening, and fall back to no-directory-rename detection
2357 * behavior for those paths.
2358 *
2359 * See testcases 9e and all of section 5 from t6043 for examples.
2360 */
2372 dir_renames);
2378 /*
2379 * dir_rename_ent->non_unique_new_path is true, which
2380 * means there is no directory rename for us to use,
2381 * which means it won't cause us any additional
2382 * collisions.
2383 */
2394 }
2397 }
2398 }
2407 {
2415 /*
2416 * This next part is a little weird. We do not want to do an
2417 * implicit rename into a directory we renamed on our side, because
2418 * that will result in a spurious rename/rename(1to2) conflict. An
2419 * example:
2420 * Base commit: dumbdir/afile, otherdir/bfile
2421 * Side 1: smrtdir/afile, otherdir/bfile
2422 * Side 2: dumbdir/afile, dumbdir/bfile
2423 * Here, while working on Side 1, we could notice that otherdir was
2424 * renamed/merged to dumbdir, and change the diff_filepair for
2425 * otherdir/bfile into a rename into dumbdir/bfile. However, Side
2426 * 2 will notice the rename from dumbdir to smrtdir, and do the
2427 * transitive rename to move it from dumbdir/bfile to
2428 * smrtdir/bfile. That gives us bfile in dumbdir vs being in
2429 * smrtdir, a rename/rename(1to2) conflict. We really just want
2430 * the file to end up in smrtdir. And the way to achieve that is
2431 * to not let Side1 do the rename to dumbdir, since we know that is
2432 * the source of one of our directory renames.
2433 *
2434 * That's why oentry and dir_rename_exclusions is here.
2435 *
2436 * As it turns out, this also prevents N-way transient rename
2437 * confusion; See testcases 9c and 9d of t6043.
2438 */
2448 }
2451 }
2462 {
2467 /*
2468 * In all cases where we can do directory rename detection,
2469 * unpack_trees() will have read pair->two->path into the
2470 * index and the working copy. We need to remove it so that
2471 * we can instead place it at new_path. It is guaranteed to
2472 * not be untracked (unpack_trees() would have errored out
2473 * saying the file would have been overwritten), but it might
2474 * be dirty, though.
2475 */
2482 /* Find or create a new re->dst_entry */
2485 /*
2486 * Since we're renaming on this side of history, and it's
2487 * due to a directory rename on the other side of history
2488 * (which we only allow when the directory in question no
2489 * longer exists on the other side of history), the
2490 * original entry for re->dst_entry is no longer
2491 * necessary...
2492 */
2495 /*
2496 * ...because we'll be using this new one.
2497 */
2500 /*
2501 * re->dst_entry is for the before-dir-rename path, and we
2502 * need it to hold information for the after-dir-rename
2503 * path. Before creating a new entry, we need to mark the
2504 * old one as unnecessary (...unless it is shared by
2505 * src_entry, i.e. this didn't use to be a rename, in which
2506 * case we can just allow the normal processing to happen
2507 * for it).
2508 */
2514 entries);
2517 }
2519 /*
2520 * Update the stage_data with the information about the path we are
2521 * moving into place. That slot will be empty and available for us
2522 * to write to because of the collision checks in
2523 * handle_path_level_conflicts(). In other words,
2524 * re->dst_entry->stages[stage].oid will be the null_oid, so it's
2525 * open for us to write to.
2526 *
2527 * It may be tempting to actually update the index at this point as
2528 * well, using update_stages_for_stage_data(), but as per the big
2529 * "NOTE" in update_stages(), doing so will modify the current
2530 * in-memory index which will break calls to would_lose_untracked()
2531 * that we need to make. Instead, we need to just make sure that
2532 * the various handle_rename_*() functions update the index
2533 * explicitly rather than relying on unpack_trees() to have done it.
2534 */
2540 /* Update pair status */
2542 /*
2543 * Recording rename information for this add makes it look
2544 * like a rename/delete conflict. Make sure we can
2545 * correctly handle this as an add that was moved to a new
2546 * directory instead of reporting a rename/delete conflict.
2547 */
2549 }
2550 /*
2551 * We don't actually look at pair->status again, but it seems
2552 * pedagogically correct to adjust it.
2553 */
2556 /*
2557 * Finally, record the new location.
2558 */
2560 }
2562 /*
2563 * Get information of all renames which occurred in 'pairs', making use of
2564 * any implicit directory renames inferred from the other side of history.
2565 * We need the three trees in the merge ('o_tree', 'a_tree' and 'b_tree')
2566 * to be able to associate the correct cache entries with the rename
2567 * information; tree is always equal to either a_tree or b_tree.
2568 */
2579 {
2598 }
2600 dir_renames,
2601 dir_rename_exclusions,
2603 clean_merge);
2607 }
2617 else
2624 else
2632 entries);
2633 }
2639 }
2642 }
2647 {
2657 }
2662 }
2682 }
2684 /* TODO: refactor, so that 1/2 are not needed */
2696 }
2702 /* BUG: We should only mark src_entry as processed if we
2703 * are not dealing with a rename + add-source case.
2704 */
2711 /* One file renamed on both sides */
2724 /* BUG: We should only remove ren1_src in
2725 * the base stage (think of rename +
2726 * add-source cases).
2727 */
2733 }
2737 branch1,
2738 branch2,
2741 o,
2742 NULL,
2743 NULL);
2745 /* Two different files renamed to the same thing */
2754 /*
2755 * BUG: We should only mark src_entry as processed
2756 * if we are not dealing with a rename + add-source
2757 * case.
2758 */
2764 branch1,
2765 branch2,
2768 o,
2773 /* Renamed in 1, maybe changed in 2 */
2774 /* we only use sha1 and mode of these */
2778 /*
2779 * unpack_trees loads entries from common-commit
2780 * into stage 1, from head-commit into stage 2, and
2781 * from merge-commit into stage 3. We keep track
2782 * of which side corresponds to the rename.
2783 */
2787 /* BUG: We should only remove ren1_src in the base
2788 * stage and in other_stage (think of rename +
2789 * add-source case).
2790 */
2806 NULL,
2807 branch1,
2808 branch2,
2810 NULL,
2811 o,
2812 NULL,
2813 NULL);
2817 NULL,
2818 branch1,
2819 branch2,
2821 NULL,
2822 o,
2823 NULL,
2824 NULL);
2827 /*
2828 * Added file on the other side identical to
2829 * the file being renamed: clean merge.
2830 * Also, there is no need to overwrite the
2831 * file already in the working copy, so call
2832 * update_file_flags() instead of
2833 * update_file().
2834 */
2838 ren1_dst,
2843 /*
2844 * Probably not a clean merge, but it's
2845 * premature to set clean_merge to 0 here,
2846 * because if the rename merges cleanly and
2847 * the merge exactly matches the newly added
2848 * file, then the merge will be clean.
2849 */
2852 NULL,
2853 branch1,
2854 branch2,
2856 NULL,
2857 o,
2859 NULL);
2876 }
2880 NULL,
2881 branch1,
2882 NULL,
2884 NULL,
2885 o,
2886 NULL,
2887 NULL);
2888 }
2889 }
2890 }
2891 cleanup_and_return:
2896 }
2901 };
2905 {
2913 /* possible_new_dirs already cleared in get_directory_renames */
2914 }
2920 }
2928 {
2954 }
2970 cleanup:
2971 /*
2972 * Some cleanup is deferred until cleanup_renames() because the
2973 * data structures are still needed and referenced in
2974 * process_entry(). But there are a few things we can free now.
2975 */
2980 }
2983 {
2993 }
2996 }
2999 {
3002 }
3005 {
3007 }
3012 {
3022 }
3025 }
3033 {
3048 /*
3049 * Note: binary | is used so that both renormalizations are
3050 * performed. Comparison can be skipped if both files are
3051 * unchanged since their sha1s have already been compared.
3052 */
3057 error_return:
3061 }
3068 {
3083 }
3091 }
3100 {
3110 }
3124 /* If rename_conflict_info->pair2 != NULL, we are in
3125 * RENAME_ONE_FILE_TO_ONE case. Otherwise, we have a
3126 * normal rename.
3127 */
3138 }
3144 /*
3145 * We can skip updating the working tree file iff:
3146 * a) The merge is clean
3147 * b) The merge matches what was in HEAD (content, mode, pathname)
3148 * c) The target path is usable (i.e. not involved in D/F conflict)
3149 */
3160 /*
3161 * However, add_cacheinfo() will delete the old cache entry
3162 * and add a new one. We need to copy over any skip_worktree
3163 * flag to avoid making the file appear as if it were
3164 * deleted by the user.
3165 */
3172 }
3174 }
3184 }
3204 }
3206 }
3210 path);
3211 }
3216 }
3222 }
3230 {
3231 /* Merge the content and write it out */
3234 ci);
3235 }
3237 /* Per entry merge function */
3240 {
3257 path,
3261 conflict_info);
3271 /*
3272 * Probably unclean merge, but if the renamed file
3273 * merges cleanly and the result can then be
3274 * two-way merged cleanly with the added file, I
3275 * guess it's a clean merge?
3276 */
3293 /*
3294 * Probably unclean merge, but if the two renamed
3295 * files merge cleanly and the two resulting files
3296 * can then be two-way merged cleanly, I guess it's
3297 * a clean merge?
3298 */
3300 conflict_info);
3305 }
3307 /* Case A: Deleted in one */
3311 /* Deleted in both or deleted in one and
3312 * unchanged in the other */
3315 /* do not touch working file if it did not exist */
3318 /* Modify/delete; deleted side may have put a directory in the way */
3323 }
3326 /* Case B: Added in one. */
3327 /* [nothing|directory] -> ([nothing|directory], file) */
3347 }
3363 /* do not overwrite file if already present */
3366 }
3369 /* Case C: Added in both (check for same permissions) */
3372 path);
3380 /* case D: Modified in both, but differently. */
3383 is_dirty,
3387 NULL);
3388 }
3390 /*
3391 * this entry was deleted altogether. a_mode == 0 means
3392 * we had that path and want to actively remove it.
3393 */
3399 }
3406 {
3415 }
3420 }
3426 }
3437 }
3443 /*
3444 * Only need the hashmap while processing entries, so
3445 * initialize it here and free it when we are done running
3446 * through the entries. Keeping it in the merge_options as
3447 * opposed to decaring a local hashmap is for convenience
3448 * so that we don't have to pass it to around.
3449 */
3470 }
3471 }
3472 }
3478 }
3480 cleanup:
3491 }
3492 }
3493 else
3502 }
3505 {
3511 }
3513 }
3515 /*
3516 * Merge the commits h1 and h2, return the resulting virtual
3517 * commit object and a flag indicating the cleanness of the merge.
3518 */
3524 {
3534 }
3539 }
3548 }
3552 /* if there is no common ancestor, use an empty tree */
3557 }
3562 /*
3563 * When the merge fails, the result contains files
3564 * with conflict markers. The cleanness flag is
3565 * ignored (unless indicating an error), it was never
3566 * actually used, as result of merge_trees has always
3567 * overwritten it: the committed "conflicts" were
3568 * already resolved.
3569 */
3584 }
3597 }
3603 }
3611 }
3615 {
3629 }
3637 {
3652 }
3653 }
3657 result);
3661 }
3668 }
3671 {
3679 }
3683 }
3685 }
3689 {
3709 }
3712 {
3733 /* clear out previous settings */
3737 }
3755 }
3761 }
3762 /*
3763 * Please update $__git_merge_strategy_options in
3764 * git-completion.bash when you add new options
3765 */
3766 else
3769 }