| blob | ca4731a719cf1c6428ae6a03e631170d6a30ed37 |
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 }
167 {
169 }
174 {
181 }
183 /*
184 * Since we use get_tree_entry(), which does not put the read object into
185 * the object pool, we cannot rely on a == b.
186 */
188 {
192 }
196 RENAME_VIA_DIR,
197 RENAME_ADD,
198 RENAME_DELETE,
199 RENAME_ONE_FILE_TO_ONE,
200 RENAME_ONE_FILE_TO_TWO,
201 RENAME_TWO_FILES_TO_ONE
202 };
214 };
216 /*
217 * Since we want to write the index eventually, we cannot reuse the index
218 * for these (temporary) data.
219 */
227 };
239 {
243 /*
244 * When we have two renames involved, it's easiest to get the
245 * correct things into stage 2 and 3, and to make sure that the
246 * content merge puts HEAD before the other branch if we just
247 * ensure that branch1 == o->branch1. So, simply flip arguments
248 * around if we don't have that.
249 */
255 o,
258 }
275 }
277 /*
278 * For each rename, there could have been
279 * modifications on the side of history where that
280 * file was not renamed.
281 */
289 }
297 }
298 }
301 {
303 }
307 {
322 }
325 {
334 DEFAULT_ABBREV);
345 }
346 }
348 }
353 {
372 }
374 }
377 {
380 }
386 {
394 else
411 /*
412 * Update o->repo->index to match the new results, AFTER saving a copy
413 * in o->orig_index. Update src_index to point to the saved copy.
414 * (verify_uptodate() checks src_index, and the original index is
415 * the one that had the necessary modification timestamps.)
416 */
422 }
425 {
428 }
431 {
443 }
445 }
454 }
459 }
464 {
477 }
480 {
485 }
491 {
498 }
500 }
502 /*
503 * Returns an index_entry instance which doesn't have to correspond to
504 * a real cache entry in Git's index.
505 */
509 {
521 }
523 /*
524 * Create a dictionary mapping file names to stage_data objects. The
525 * dictionary contains one entry for every path with a non-zero stage entry.
526 */
528 {
545 }
549 }
552 }
555 {
558 /*
559 * Here we only care that entries for D/F conflicts are
560 * adjacent, in particular with the file of the D/F conflict
561 * appearing before files below the corresponding directory.
562 * The order of the rest of the list is irrelevant for us.
563 *
564 * To achieve this, we sort with df_name_compare and provide
565 * the mode S_IFDIR so that D/F conflicts will sort correctly.
566 * We use the mode S_IFDIR for everything else for simplicity,
567 * since in other cases any changes in their order due to
568 * sorting cause no problems for us.
569 */
572 /*
573 * Now that 'foo' and 'foo/bar' compare equal, we have to make sure
574 * that 'foo' comes before 'foo/bar'.
575 */
579 }
583 {
584 /* If there is a D/F conflict and the file for such a conflict
585 * currently exists in the working tree, we want to allow it to be
586 * removed to make room for the corresponding directory if needed.
587 * The files underneath the directories of such D/F conflicts will
588 * be processed before the corresponding file involved in the D/F
589 * conflict. If the D/F directory ends up being removed by the
590 * merge, then we won't have to touch the D/F file. If the D/F
591 * directory needs to be written to the working copy, then the D/F
592 * file will simply be removed (in make_room_for_path()) to make
593 * room for the necessary paths. Note that if both the directory
594 * and the file need to be present, then the D/F file will be
595 * reinstated with a new unique name at the time it is processed.
596 */
602 /*
603 * If we're merging merge-bases, we don't want to bother with
604 * any working directory changes.
605 */
609 /* Ensure D/F conflicts are adjacent in the entries list. */
614 }
624 /*
625 * Check if last_file & path correspond to a D/F conflict;
626 * i.e. whether path is last_file+'/'+<something>.
627 * If so, record that it's okay to remove last_file to make
628 * room for path and friends if needed.
629 */
635 }
637 /*
638 * Determine whether path could exist as a file in the
639 * working directory as a possible D/F conflict. This
640 * will only occur when it exists in stage 2 as a
641 * file.
642 */
648 }
649 }
651 }
655 /*
656 * Purpose of src_entry and dst_entry:
657 *
658 * If 'before' is renamed to 'after' then src_entry will contain
659 * the versions of 'before' from the merge_base, HEAD, and MERGE in
660 * stages 1, 2, and 3; dst_entry will contain the respective
661 * versions of 'after' in corresponding locations. Thus, we have a
662 * total of six modes and oids, though some will be null. (Stage 0
663 * is ignored; we're interested in handling conflicts.)
664 *
665 * Since we don't turn on break-rewrites by default, neither
666 * src_entry nor dst_entry can have all three of their stages have
667 * non-null oids, meaning at most four of the six will be non-null.
668 * Also, since this is a rename, both src_entry and dst_entry will
669 * have at least one non-null oid, meaning at least two will be
670 * non-null. Of the six oids, a typical rename will have three be
671 * non-null. Only two implies a rename/delete, and four implies a
672 * rename/add.
673 */
678 };
684 {
686 /*
687 * NOTE: It is usually a bad idea to call update_stages on a path
688 * before calling update_file on that same path, since it can
689 * sometimes lead to spurious "refusing to lose untracked file..."
690 * messages from update_file (via make_room_for path via
691 * would_lose_untracked). Instead, reverse the order of the calls
692 * (executing update_file first and then update_stages).
693 */
709 }
715 {
723 }
727 {
734 }
739 ignore_case);
742 }
745 }
747 }
749 /* add a string to a strbuf, but converting "/" to "_" */
751 {
757 }
760 {
775 }
781 }
783 /**
784 * Check whether a directory in the index is in the way of an incoming
785 * file. Return 1 if so. If check_working_copy is non-zero, also
786 * check the working directory. If empty_ok is non-zero, also return
787 * 0 in the case where the working-tree dir exists but is empty.
788 */
791 {
807 }
812 }
814 /*
815 * Returns whether path was tracked in the index before the merge started,
816 * and its oid and mode match the specified values
817 */
820 {
825 /* we were not tracking this path before the merge */
828 /* See if the file we were tracking before matches */
831 }
833 /*
834 * Returns whether path was tracked in the index before the merge started
835 */
837 {
841 /* we were tracking this path before the merge */
845 }
848 {
851 /*
852 * This may look like it can be simplified to:
853 * return !was_tracked(o, path) && file_exists(path)
854 * but it can't. This function needs to know whether path was in
855 * the working tree due to EITHER having been tracked in the index
856 * before the merge OR having been put into the working copy and
857 * index by unpack_trees(). Due to that either-or requirement, we
858 * check the current index instead of the original one.
859 *
860 * Note that we do not need to worry about merge-recursive itself
861 * updating the index after unpack_trees() and before calling this
862 * function, because we strictly require all code paths in
863 * merge-recursive to update the working tree first and the index
864 * second. Doing otherwise would break
865 * update_file()/would_lose_untracked(); see every comment in this
866 * file which mentions "update_stages".
867 */
874 /*
875 * If stage #0, it is definitely tracked.
876 * If it has stage #2 then it was tracked
877 * before this merge started. All other
878 * cases the path was not tracked.
879 */
884 }
885 pos++;
886 }
888 }
891 {
902 }
905 {
909 /* Unlink any D/F conflict files that are in the way */
919 df_path);
924 }
925 }
927 /* Make sure leading directories are created */
931 /* something else exists */
934 }
936 /*
937 * Do not unlink a file in the work tree if we are not
938 * tracking it.
939 */
942 path);
944 /* Successful unlink is good.. */
947 /* .. and so is no existing file */
950 /* .. but not some other error (who really cares what?) */
952 }
960 {
972 /*
973 * We may later decide to recursively descend into
974 * the submodule directory and update its index
975 * and/or work tree, but we do not do that now.
976 */
979 }
987 }
994 }
995 }
1000 }
1005 else
1012 }
1027 free_buf:
1029 }
1030 update_index:
1033 ADD_CACHE_OK_TO_ADD))
1036 }
1043 {
1045 }
1047 /* Low level file merging, update and removal */
1054 };
1064 {
1088 }
1089 }
1102 }
1119 }
1124 {
1139 /* get all revisions that merge commit a */
1144 /* FIXME: can't handle linked worktrees in submodules yet */
1148 /* save all revisions from the above list that contain b */
1155 }
1158 /* Now we've got all merges that contain a and b. Prune all
1159 * merges that contain another found merge and save them in
1160 * result.
1161 */
1171 }
1172 }
1176 }
1180 }
1183 {
1190 }
1196 {
1204 /* store a in result in case we fail */
1207 /* we can not handle deletion conflicts */
1218 }
1225 }
1227 /* check whether both changes are forward */
1232 }
1234 /* Case #1: a is contained in b or vice versa */
1242 else
1246 }
1254 else
1258 }
1260 /*
1261 * Case #2: There are one or more merges that contain a and b in
1262 * the submodule. If there is only one, then present it as a
1263 * suggestion to the user, but leave it marked unmerged so the
1264 * user needs to confirm the resolution.
1265 */
1267 /* Skip the search if makes no sense to the calling context. */
1271 /* find commit which merges them */
1284 "If this is correct simply add it to the index "
1296 }
1300 }
1311 {
1313 /*
1314 * It's weird getting a reverse merge with HEAD on the bottom
1315 * side of the conflict markers and the other branch on the
1316 * top. Fix that.
1317 */
1319 filename,
1322 }
1335 }
1340 /*
1341 * Merge modes
1342 */
1350 }
1351 }
1358 mmbuffer_t result_buf;
1363 extra_marker_size);
1397 }
1400 }
1406 }
1411 {
1412 /*
1413 * Handle file adds that need to be renamed due to directory rename
1414 * detection. This differs from handle_rename_normal, because
1415 * there is no content merge to do; just move the file into the
1416 * desired final location.
1417 */
1426 /*
1427 * Write the file in worktree at alt_path, but not in the
1428 * index. Instead, write to dest->path for the index but
1429 * only at the higher appropriate stage.
1430 */
1437 }
1439 /* Update dest->path both in index and in worktree */
1443 }
1453 {
1461 }
1464 /*
1465 * We cannot arbitrarily accept either a_sha or b_sha as
1466 * correct; since there is no true "middle point" between
1467 * them, simply reuse the base version for virtual merge base.
1468 */
1473 /*
1474 * Despite the four nearly duplicate messages and argument
1475 * lists below and the ugliness of the nested if-statements,
1476 * having complete messages makes the job easier for
1477 * translators.
1478 *
1479 * The slight variance among the cases is due to the fact
1480 * that:
1481 * 1) directory/file conflicts (in effect if
1482 * !alt_path) could cause us to need to write the
1483 * file to a different path.
1484 * 2) renames (in effect if !old_path) could mean that
1485 * there are two names for the path that the user
1486 * may know the file by.
1487 */
1499 }
1511 }
1512 }
1513 /*
1514 * No need to call update_file() on path when change_branch ==
1515 * o->branch1 && !alt_path, since that would needlessly touch
1516 * path. We could call update_file_flags() with update_cache=0
1517 * and update_wd=0, but that's a no-op.
1518 */
1521 }
1525 }
1531 {
1546 else
1550 }
1555 {
1563 }
1574 {
1580 /*
1581 * It's easiest to get the correct things into stage 2 and 3, and
1582 * to make sure that the content merge puts HEAD before the other
1583 * branch if we just ensure that branch1 == o->branch1. So, simply
1584 * flip arguments around if we don't have that.
1585 */
1592 }
1594 /*
1595 * In the recursive case, we just opt to undo renames
1596 */
1598 /* Put first file (a_oid, a_mode) in its original spot */
1605 }
1607 /* Put second file (b_oid, b_mode) in its original spot */
1614 }
1616 /* Don't leave something at collision path if unrenaming both */
1621 }
1623 /* Remove rename sources if rename/add or rename/rename(2to1) */
1631 /*
1632 * Remove the collision path, if it wouldn't cause dirty contents
1633 * or an untracked file to get lost. We'll either overwrite with
1634 * merged contents, or just write out to differently named files.
1635 */
1638 collide_path);
1641 /*
1642 * Only way we get here is if both renames were from
1643 * a directory rename AND user had an untracked file
1644 * at the location where both files end up after the
1645 * two directory renames. See testcase 10d of t6043.
1646 */
1649 collide_path);
1652 /*
1653 * FIXME: It's possible that the two files are identical
1654 * and that the current working copy happens to match, in
1655 * which case we are unnecessarily touching the working
1656 * tree file. It's not a likely enough scenario that I
1657 * want to code up the checks for it and a better fix is
1658 * available if we restructure how unpack_trees() and
1659 * merge-recursive interoperate anyway, so punting for
1660 * now...
1661 */
1663 }
1665 /* Store things in diff_filespecs for functions that need it */
1688 /*
1689 * FIXME: If both a & b both started with conflicts (only possible
1690 * if they came from a rename/rename(2to1)), but had IDENTICAL
1691 * contents including those conflicts, then in the next line we claim
1692 * it was clean. If someone cares about this case, we should have the
1693 * caller notify us if we started with conflicts.
1694 */
1696 }
1700 {
1701 /* a was renamed to c, and a separate c was added. */
1728 }
1734 {
1746 }
1749 }
1753 {
1754 /* One file was renamed in both branches, but to different names. */
1779 /*
1780 * FIXME: For rename/add-source conflicts (if we could detect
1781 * such), this is wrong. We should instead find a unique
1782 * pathname and then either rename the add-source file to that
1783 * unique path, or use that unique path instead of src here.
1784 */
1788 /*
1789 * Above, we put the merged content at the merge-base's
1790 * path. Now we usually need to delete both a->path and
1791 * b->path. However, the rename on each side of the merge
1792 * could also be involved in a rename/add conflict. In
1793 * such cases, we should keep the added file around,
1794 * resolving the conflict at that path in its favor.
1795 */
1800 }
1801 else
1807 }
1808 else
1811 /*
1812 * For each destination path, we need to see if there is a
1813 * rename/add collision. If not, we can write the file out
1814 * to the specified location.
1815 */
1833 }
1852 }
1853 }
1856 }
1860 {
1861 /* Two files, a & b, were renamed to the same thing, c. */
1873 "Rename %s->%s in %s. "
1894 }
1896 /*
1897 * Get the diff_filepairs changed between o_tree and tree.
1898 */
1902 {
1910 /*
1911 * We do not have logic to handle the detection of copies. In
1912 * fact, it may not even make sense to add such logic: would we
1913 * really want a change to a base file to be propagated through
1914 * multiple other files by a merge?
1915 */
1938 }
1941 {
1947 }
1949 /*
1950 * Return a new string that replaces the beginning portion (which matches
1951 * entry->dir), with entry->new_dir. In perl-speak:
1952 * new_path_name = (old_path =~ s/entry->dir/entry->new_dir/);
1953 * NOTE:
1954 * Caller must ensure that old_path starts with entry->dir + '/'.
1955 */
1958 {
1972 }
1976 {
1983 /*
1984 * For
1985 * "a/b/c/d/e/foo.c" -> "a/b/some/thing/else/e/foo.c"
1986 * the "e/foo.c" part is the same, we just want to know that
1987 * "a/b/c/d" was renamed to "a/b/some/thing/else"
1988 * so, for this example, this function returns "a/b/c/d" in
1989 * *old_dir and "a/b/some/thing/else" in *new_dir.
1990 *
1991 * Also, if the basename of the file changed, we don't care. We
1992 * want to know which portion of the directory, if any, changed.
1993 */
2003 /*
2004 * We've found the first non-matching character in the directory
2005 * paths. That means the current directory we were comparing
2006 * represents the rename. Move end_of_old and end_of_new back
2007 * to the full directory name.
2008 */
2010 end_of_old++;
2012 end_of_new++;
2016 /*
2017 * It may have been the case that old_path and new_path were the same
2018 * directory all along. Don't claim a rename if they're the same.
2019 */
2026 }
2027 }
2031 {
2038 }
2040 }
2042 /*
2043 * See if there is a directory rename for path, and if there are any file
2044 * level conflicts for the renamed location. If there is a rename and
2045 * there are no conflicts, return the new name. Otherwise, return NULL.
2046 */
2052 {
2058 /*
2059 * entry has the mapping of old directory name to new directory name
2060 * that we want to apply to path.
2061 */
2065 /* This should only happen when entry->non_unique_new_dir set */
2069 "Unclear where to place %s because directory "
2070 "%s was renamed to multiple other directories, "
2071 "with no destination getting a majority of the "
2076 }
2078 /*
2079 * The caller needs to have ensured that it has pre-populated
2080 * collisions with all paths that map to new_path. Do a quick check
2081 * to ensure that's the case.
2082 */
2087 /*
2088 * Check for one-sided add/add/.../add conflicts, i.e.
2089 * where implicit renames from the other side doing
2090 * directory rename(s) can affect this side of history
2091 * to put multiple paths into the same location. Warn
2092 * and bail on directory renames for such paths.
2093 */
2101 "file/dir at %s in the way of implicit "
2102 "directory rename(s) putting the following "
2111 "more than one path to %s; implicit directory "
2115 }
2117 /* Free memory we no longer need */
2122 }
2125 }
2127 /*
2128 * There are a couple things we want to do at the directory level:
2129 * 1. Check for both sides renaming to the same thing, in order to avoid
2130 * implicit renaming of files that should be left in place. (See
2131 * testcase 6b in t6043 for details.)
2132 * 2. Prune directory renames if there are still files left in the
2133 * the original directory. These represent a partial directory rename,
2134 * i.e. a rename where only some of the files within the directory
2135 * were renamed elsewhere. (Technically, this could be done earlier
2136 * in get_directory_renames(), except that would prevent us from
2137 * doing the previous check and thus failing testcase 6b.)
2138 * 3. Check for rename/rename(1to2) conflicts (at the directory level).
2139 * In the future, we could potentially record this info as well and
2140 * omit reporting rename/rename(1to2) conflicts for each path within
2141 * the affected directories, thus cleaning up the merge output.
2142 * NOTE: We do NOT check for rename/rename(2to1) conflicts at the
2143 * directory level, because merging directories is fine. If it
2144 * causes conflicts for files within those merged directories, then
2145 * that should be detected at the individual path level.
2146 */
2152 {
2167 /* 1. Renamed identically; remove it from both sides */
2175 /* 2. This wasn't a directory rename after all */
2179 }
2180 }
2189 /* 2. This wasn't a directory rename after all */
2195 /* 3. rename/rename(1to2) */
2196 /*
2197 * We can assume it's not rename/rename(1to1) because
2198 * that was case (1), already checked above. So we
2199 * know that head_ent->new_dir and merge_ent->new_dir
2200 * are different strings.
2201 */
2203 "Rename directory %s->%s in %s. "
2213 }
2214 }
2218 }
2221 {
2227 /*
2228 * Typically, we think of a directory rename as all files from a
2229 * certain directory being moved to a target directory. However,
2230 * what if someone first moved two files from the original
2231 * directory in one commit, and then renamed the directory
2232 * somewhere else in a later commit? At merge time, we just know
2233 * that files from the original directory went to two different
2234 * places, and that the bulk of them ended up in the same place.
2235 * We want each directory rename to represent where the bulk of the
2236 * files from that directory end up; this function exists to find
2237 * where the bulk of the files went.
2238 *
2239 * The first loop below simply iterates through the list of file
2240 * renames, finding out how often each directory rename pair
2241 * possibility occurs.
2242 */
2251 /* File not part of directory rename if it wasn't renamed */
2258 /* Directory didn't change at all; ignore this one. */
2268 }
2272 new_dir);
2276 }
2279 }
2281 /*
2282 * For each directory with files moved out of it, we find out which
2283 * target directory received the most files so we can declare it to
2284 * be the "winning" target location for the directory rename. This
2285 * winner gets recorded in new_dir. If there is no winner
2286 * (multiple target directories received the same number of files),
2287 * we set non_unique_new_dir. Once we've determined the winner (or
2288 * that there is no winner), we no longer need possible_new_dirs.
2289 */
2304 }
2305 }
2311 }
2312 /*
2313 * The relevant directory sub-portion of the original full
2314 * filepaths were xstrndup'ed before inserting into
2315 * possible_new_dirs, and instead of manually iterating the
2316 * list and free'ing each, just lie and tell
2317 * possible_new_dirs that it did the strdup'ing so that it
2318 * will free them for us.
2319 */
2322 }
2325 }
2329 {
2339 }
2342 }
2347 {
2350 /*
2351 * Multiple files can be mapped to the same path due to directory
2352 * renames done by the other side of history. Since that other
2353 * side of history could have merged multiple directories into one,
2354 * if our side of history added the same file basename to each of
2355 * those directories, then all N of them would get implicitly
2356 * renamed by the directory rename detection into the same path,
2357 * and we'd get an add/add/.../add conflict, and all those adds
2358 * from *this* side of history. This is not representable in the
2359 * index, and users aren't going to easily be able to make sense of
2360 * it. So we need to provide a good warning about what's
2361 * happening, and fall back to no-directory-rename detection
2362 * behavior for those paths.
2363 *
2364 * See testcases 9e and all of section 5 from t6043 for examples.
2365 */
2377 dir_renames);
2383 /*
2384 * dir_rename_ent->non_unique_new_path is true, which
2385 * means there is no directory rename for us to use,
2386 * which means it won't cause us any additional
2387 * collisions.
2388 */
2399 }
2402 }
2403 }
2412 {
2420 /*
2421 * This next part is a little weird. We do not want to do an
2422 * implicit rename into a directory we renamed on our side, because
2423 * that will result in a spurious rename/rename(1to2) conflict. An
2424 * example:
2425 * Base commit: dumbdir/afile, otherdir/bfile
2426 * Side 1: smrtdir/afile, otherdir/bfile
2427 * Side 2: dumbdir/afile, dumbdir/bfile
2428 * Here, while working on Side 1, we could notice that otherdir was
2429 * renamed/merged to dumbdir, and change the diff_filepair for
2430 * otherdir/bfile into a rename into dumbdir/bfile. However, Side
2431 * 2 will notice the rename from dumbdir to smrtdir, and do the
2432 * transitive rename to move it from dumbdir/bfile to
2433 * smrtdir/bfile. That gives us bfile in dumbdir vs being in
2434 * smrtdir, a rename/rename(1to2) conflict. We really just want
2435 * the file to end up in smrtdir. And the way to achieve that is
2436 * to not let Side1 do the rename to dumbdir, since we know that is
2437 * the source of one of our directory renames.
2438 *
2439 * That's why oentry and dir_rename_exclusions is here.
2440 *
2441 * As it turns out, this also prevents N-way transient rename
2442 * confusion; See testcases 9c and 9d of t6043.
2443 */
2453 }
2456 }
2467 {
2472 /*
2473 * In all cases where we can do directory rename detection,
2474 * unpack_trees() will have read pair->two->path into the
2475 * index and the working copy. We need to remove it so that
2476 * we can instead place it at new_path. It is guaranteed to
2477 * not be untracked (unpack_trees() would have errored out
2478 * saying the file would have been overwritten), but it might
2479 * be dirty, though.
2480 */
2487 /* Find or create a new re->dst_entry */
2490 /*
2491 * Since we're renaming on this side of history, and it's
2492 * due to a directory rename on the other side of history
2493 * (which we only allow when the directory in question no
2494 * longer exists on the other side of history), the
2495 * original entry for re->dst_entry is no longer
2496 * necessary...
2497 */
2500 /*
2501 * ...because we'll be using this new one.
2502 */
2505 /*
2506 * re->dst_entry is for the before-dir-rename path, and we
2507 * need it to hold information for the after-dir-rename
2508 * path. Before creating a new entry, we need to mark the
2509 * old one as unnecessary (...unless it is shared by
2510 * src_entry, i.e. this didn't use to be a rename, in which
2511 * case we can just allow the normal processing to happen
2512 * for it).
2513 */
2519 entries);
2522 }
2524 /*
2525 * Update the stage_data with the information about the path we are
2526 * moving into place. That slot will be empty and available for us
2527 * to write to because of the collision checks in
2528 * handle_path_level_conflicts(). In other words,
2529 * re->dst_entry->stages[stage].oid will be the null_oid, so it's
2530 * open for us to write to.
2531 *
2532 * It may be tempting to actually update the index at this point as
2533 * well, using update_stages_for_stage_data(), but as per the big
2534 * "NOTE" in update_stages(), doing so will modify the current
2535 * in-memory index which will break calls to would_lose_untracked()
2536 * that we need to make. Instead, we need to just make sure that
2537 * the various handle_rename_*() functions update the index
2538 * explicitly rather than relying on unpack_trees() to have done it.
2539 */
2545 /* Update pair status */
2547 /*
2548 * Recording rename information for this add makes it look
2549 * like a rename/delete conflict. Make sure we can
2550 * correctly handle this as an add that was moved to a new
2551 * directory instead of reporting a rename/delete conflict.
2552 */
2554 }
2555 /*
2556 * We don't actually look at pair->status again, but it seems
2557 * pedagogically correct to adjust it.
2558 */
2561 /*
2562 * Finally, record the new location.
2563 */
2565 }
2567 /*
2568 * Get information of all renames which occurred in 'pairs', making use of
2569 * any implicit directory renames inferred from the other side of history.
2570 * We need the three trees in the merge ('o_tree', 'a_tree' and 'b_tree')
2571 * to be able to associate the correct cache entries with the rename
2572 * information; tree is always equal to either a_tree or b_tree.
2573 */
2584 {
2603 }
2605 dir_renames,
2606 dir_rename_exclusions,
2608 clean_merge);
2612 }
2622 else
2629 else
2637 entries);
2638 }
2644 }
2647 }
2652 {
2662 }
2667 }
2687 }
2689 /* TODO: refactor, so that 1/2 are not needed */
2701 }
2707 /* BUG: We should only mark src_entry as processed if we
2708 * are not dealing with a rename + add-source case.
2709 */
2716 /* One file renamed on both sides */
2729 /* BUG: We should only remove ren1_src in
2730 * the base stage (think of rename +
2731 * add-source cases).
2732 */
2738 }
2742 branch1,
2743 branch2,
2746 o,
2747 NULL,
2748 NULL);
2750 /* Two different files renamed to the same thing */
2759 /*
2760 * BUG: We should only mark src_entry as processed
2761 * if we are not dealing with a rename + add-source
2762 * case.
2763 */
2769 branch1,
2770 branch2,
2773 o,
2778 /* Renamed in 1, maybe changed in 2 */
2779 /* we only use sha1 and mode of these */
2783 /*
2784 * unpack_trees loads entries from common-commit
2785 * into stage 1, from head-commit into stage 2, and
2786 * from merge-commit into stage 3. We keep track
2787 * of which side corresponds to the rename.
2788 */
2792 /* BUG: We should only remove ren1_src in the base
2793 * stage and in other_stage (think of rename +
2794 * add-source case).
2795 */
2811 NULL,
2812 branch1,
2813 branch2,
2815 NULL,
2816 o,
2817 NULL,
2818 NULL);
2822 NULL,
2823 branch1,
2824 branch2,
2826 NULL,
2827 o,
2828 NULL,
2829 NULL);
2832 /*
2833 * Added file on the other side identical to
2834 * the file being renamed: clean merge.
2835 * Also, there is no need to overwrite the
2836 * file already in the working copy, so call
2837 * update_file_flags() instead of
2838 * update_file().
2839 */
2843 ren1_dst,
2848 /*
2849 * Probably not a clean merge, but it's
2850 * premature to set clean_merge to 0 here,
2851 * because if the rename merges cleanly and
2852 * the merge exactly matches the newly added
2853 * file, then the merge will be clean.
2854 */
2857 NULL,
2858 branch1,
2859 branch2,
2861 NULL,
2862 o,
2864 NULL);
2881 }
2885 NULL,
2886 branch1,
2887 NULL,
2889 NULL,
2890 o,
2891 NULL,
2892 NULL);
2893 }
2894 }
2895 }
2896 cleanup_and_return:
2901 }
2906 };
2910 {
2918 /* possible_new_dirs already cleared in get_directory_renames */
2919 }
2925 }
2933 {
2959 }
2975 cleanup:
2976 /*
2977 * Some cleanup is deferred until cleanup_renames() because the
2978 * data structures are still needed and referenced in
2979 * process_entry(). But there are a few things we can free now.
2980 */
2985 }
2988 {
2998 }
3001 }
3004 {
3007 }
3010 {
3012 }
3017 {
3027 }
3030 }
3038 {
3053 /*
3054 * Note: binary | is used so that both renormalizations are
3055 * performed. Comparison can be skipped if both files are
3056 * unchanged since their sha1s have already been compared.
3057 */
3062 error_return:
3066 }
3073 {
3088 }
3096 }
3105 {
3115 }
3129 /* If rename_conflict_info->pair2 != NULL, we are in
3130 * RENAME_ONE_FILE_TO_ONE case. Otherwise, we have a
3131 * normal rename.
3132 */
3143 }
3149 /*
3150 * We can skip updating the working tree file iff:
3151 * a) The merge is clean
3152 * b) The merge matches what was in HEAD (content, mode, pathname)
3153 * c) The target path is usable (i.e. not involved in D/F conflict)
3154 */
3165 /*
3166 * However, add_cacheinfo() will delete the old cache entry
3167 * and add a new one. We need to copy over any skip_worktree
3168 * flag to avoid making the file appear as if it were
3169 * deleted by the user.
3170 */
3177 }
3179 }
3189 }
3209 }
3211 }
3215 path);
3216 }
3221 }
3227 }
3235 {
3236 /* Merge the content and write it out */
3239 ci);
3240 }
3242 /* Per entry merge function */
3245 {
3262 path,
3266 conflict_info);
3276 /*
3277 * Probably unclean merge, but if the renamed file
3278 * merges cleanly and the result can then be
3279 * two-way merged cleanly with the added file, I
3280 * guess it's a clean merge?
3281 */
3298 /*
3299 * Probably unclean merge, but if the two renamed
3300 * files merge cleanly and the two resulting files
3301 * can then be two-way merged cleanly, I guess it's
3302 * a clean merge?
3303 */
3305 conflict_info);
3310 }
3312 /* Case A: Deleted in one */
3316 /* Deleted in both or deleted in one and
3317 * unchanged in the other */
3320 /* do not touch working file if it did not exist */
3323 /* Modify/delete; deleted side may have put a directory in the way */
3328 }
3331 /* Case B: Added in one. */
3332 /* [nothing|directory] -> ([nothing|directory], file) */
3352 }
3368 /* do not overwrite file if already present */
3371 }
3374 /* Case C: Added in both (check for same permissions) */
3377 path);
3385 /* case D: Modified in both, but differently. */
3388 is_dirty,
3392 NULL);
3393 }
3395 /*
3396 * this entry was deleted altogether. a_mode == 0 means
3397 * we had that path and want to actively remove it.
3398 */
3404 }
3411 {
3420 }
3425 }
3431 }
3442 }
3448 /*
3449 * Only need the hashmap while processing entries, so
3450 * initialize it here and free it when we are done running
3451 * through the entries. Keeping it in the merge_options as
3452 * opposed to decaring a local hashmap is for convenience
3453 * so that we don't have to pass it to around.
3454 */
3475 }
3476 }
3477 }
3483 }
3485 cleanup:
3496 }
3497 }
3498 else
3507 }
3510 {
3516 }
3518 }
3520 /*
3521 * Merge the commits h1 and h2, return the resulting virtual
3522 * commit object and a flag indicating the cleanness of the merge.
3523 */
3529 {
3539 }
3544 }
3553 }
3557 /* if there is no common ancestor, use an empty tree */
3562 }
3567 /*
3568 * When the merge fails, the result contains files
3569 * with conflict markers. The cleanness flag is
3570 * ignored (unless indicating an error), it was never
3571 * actually used, as result of merge_trees has always
3572 * overwritten it: the committed "conflicts" were
3573 * already resolved.
3574 */
3589 }
3602 }
3608 }
3616 }
3620 {
3634 }
3642 {
3657 }
3658 }
3662 result);
3666 }
3673 }
3676 {
3684 }
3688 }
3690 }
3694 {
3714 }
3717 {
3738 /* clear out previous settings */
3742 }
3760 }
3766 }
3767 /*
3768 * Please update $__git_merge_strategy_options in
3769 * git-completion.bash when you add new options
3770 */
3771 else
3774 }