summaryrefslogtreecommitdiff
path: root/merge-recursive.c
AgeCommit message (Collapse)AuthorFilesLines
2013-01-16diff: Introduce --diff-algorithm command line optionLibravatar Michal Privoznik1-0/+9
Since command line options have higher priority than config file variables and taking previous commit into account, we need a way how to specify myers algorithm on command line. However, inventing `--myers` is not the right answer. We need far more general option, and that is `--diff-algorithm`. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-09Which merge_file() function do you mean?Libravatar Junio C Hamano1-3/+3
There are two different static functions and one global function, all of them called "merge_file()", with different signatures and purposes. Rename them all to reduce confusion in "git grep" output: * Rename the static one in merge-index to "merge_one_path(const char *path)" as that function is about asking an external command to resolve conflicts in one path. * Rename the global one in merge-file.c that is only used by merge-tree to "merge_blobs()", as the function takes three blobs and returns the merged result only in-core, without doing anything to the filesystem. * Rename the one in merge-recursive to "merge_one_file()", just to be fair. Also rename merge-file.[ch] to merge-blobs.[ch]. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-14Merge branch 'rj/path-cleanup'Libravatar Junio C Hamano1-6/+7
* rj/path-cleanup: Call mkpathdup() rather than xstrdup(mkpath(...)) Call git_pathdup() rather than xstrdup(git_path("...")) path.c: Use vsnpath() in the implementation of git_path() path.c: Don't discard the return value of vsnpath() path.c: Remove the 'git_' prefix from a file scope function
2012-09-04Call mkpathdup() rather than xstrdup(mkpath(...))Libravatar Ramsay Jones1-6/+7
In addition to updating the xstrdup(mkpath(...)) call sites with mkpathdup(), we also fix a memory leak (in merge_3way()) caused by neglecting to free the memory allocated to the 'base_name' variable. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-22Merge branch 'tr/void-diff-setup-done'Libravatar Junio C Hamano1-2/+1
Remove unnecessary code. * tr/void-diff-setup-done: diff_setup_done(): return void
2012-08-22Merge branch 'tr/merge-recursive-flush'Libravatar Junio C Hamano1-18/+1
Remove unnecessary code. * tr/merge-recursive-flush: merge-recursive: eliminate flush_buffer() in favor of write_in_full()
2012-08-05merge-recursive: separate message for common ancestorsLibravatar Ralf Thielow1-1/+4
The function "merge_recursive" prints the count of common ancestors as "found %u common ancestor(s):". We should use a singular and a plural form of this message to help translators. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-03merge-recursive: eliminate flush_buffer() in favor of write_in_full()Libravatar Thomas Rast1-18/+1
flush_buffer() is a thin wrapper around write_in_full() with two very confusing properties: * It runs a loop to handle short reads, ensuring that we write everything. But that is precisely what write_in_full() does! * It checks for a return value of 0 from write_in_full(), which cannot happen: it returns this value only if count=0, but flush_buffer() will never call write_in_full() in this case. Remove it. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-03diff_setup_done(): return voidLibravatar Thomas Rast1-2/+1
diff_setup_done() has historically returned an error code, but lost the last nonzero return in 943d5b7 (allow diff.renamelimit to be set regardless of -M/-C, 2006-08-09). The callers were in a pretty confused state: some actually checked for the return code, and some did not. Let it return void, and patch all callers to take this into account. This conveniently also gets rid of a handful of different(!) error messages that could never be triggered anyway. Note that the function can still die(). Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-26i18n: merge-recursive: mark strings for translationLibravatar Jiang Xin1-69/+79
Mark strings in merge-recursive for translation. Some tests would start to fail with GETTEXT_POISON turned on after this update. Use test_i18ncmp and test_i18ngrep where appropriate to mark strings that should only be checked in the C locale output to avoid such issues. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Reviewed-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-16Merge branch 'jk/diff-no-rename-empty'Libravatar Junio C Hamano1-1/+2
Forbids rename detection logic from matching two empty files as renames during merge-recursive to prevent mismerges. By Jeff King * jk/diff-no-rename-empty: merge-recursive: don't detect renames of empty files teach diffcore-rename to optionally ignore empty content make is_empty_blob_sha1 available everywhere drop casts from users EMPTY_TREE_SHA1_BIN
2012-04-15Merge branch 'jc/diff-algo-cleanup'Libravatar Junio C Hamano1-2/+2
Resurrects the preparatory clean-up patches from another topic that was discarded, as this would give a saner foundation to build on diff.algo configuration option series. * jc/diff-algo-cleanup: xdiff: PATIENCE/HISTOGRAM are not independent option bits xdiff: remove XDL_PATCH_* macros
2012-03-23merge-recursive: don't detect renames of empty filesLibravatar Jeff King1-0/+1
Merge-recursive detects renames so that if one side modifies "foo" and the other side moves it to "bar", the modification is applied to "bar". However, our rename detection is based on content analysis, it can be wrong (i.e., two files were not intended as a rename, but just happen to have the same or similar content). This is quite rare if the files actually contain content, since two unrelated files are unlikely to have exactly the same content. However, empty files present a problem, in that there is nothing to analyze. An uninteresting placeholder file with zero bytes may or may not be related to a placeholder file with another name. The result is that adding content to an empty file may cause confusion if the other side of a merge removed it; your content may end up in another random placeholder file that was added. Let's err on the side of caution and not consider empty files as renames. This will cause a modify/delete conflict on the merge, which will let the user sort it out themselves. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-23drop casts from users EMPTY_TREE_SHA1_BINLibravatar Jeff King1-1/+1
This macro already evaluates to the correct type, as it casts the string literal to "unsigned char *" itself (and callers who want the literal can use the _LITERAL form). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-19xdiff: PATIENCE/HISTOGRAM are not independent option bitsLibravatar Junio C Hamano1-2/+2
Because the default Myers, patience and histogram algorithms cannot be in effect at the same time, XDL_PATIENCE_DIFF and XDL_HISTOGRAM_DIFF are not independent bits. Instead of wasting one bit per algorithm, define a few macros to access the few bits they occupy and update the code that access them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-07cache-tree: update API to take abitrary flagsLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-19Merge branch 'tr/cache-tree'Libravatar Junio C Hamano1-1/+1
* tr/cache-tree: reset: update cache-tree data when appropriate commit: write cache-tree data when writing index anyway Refactor cache_tree_update idiom from commit Test the current state of the cache-tree optimization Add test-scrap-cache-tree
2011-12-06Refactor cache_tree_update idiom from commitLibravatar Thomas Rast1-1/+1
We'll need to safely create or update the cache-tree data of the_index from other places. While at it, give it an argument that lets us silence the messages produced by unmerged entries (which prevent it from working). Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-08merge: make usage of commit->util more extensibleLibravatar Junio C Hamano1-7/+6
The merge-recursive code uses the commit->util field directly to annotate the commit objects given from the command line, i.e. the remote heads to be merged, with a single string to be used to describe it in its trace messages and conflict markers. Correct this short-signtedness by redefining the field to be a pointer to a structure "struct merge_remote_desc" that later enhancements can add more information. Store the original objects we were told to merge in a field "obj" in this struct, so that we can recover the tag we were told to merge. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-13submodule: Search for merges only at end of recursive mergeLibravatar Brad King1-2/+4
The submodule merge search is not useful during virtual merges because the results cannot be used automatically. Furthermore any suggestions made by the search may apply to commits different than HEAD:sub and MERGE_HEAD:sub, thus confusing the user. Skip searching for submodule merges during a virtual merge such as that between B and C while merging the heads of: B---BC / \ / A X \ / \ C---CB Run the search only when the recursion level is zero (!o->call_depth). This fixes known breakage tested in t7405-submodule-merge. Signed-off-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Merge branch 'cn/eradicate-working-copy'Libravatar Junio C Hamano1-1/+1
* cn/eradicate-working-copy: Remove 'working copy' from the documentation and C code
2011-09-23merge-recursive: Do not look at working tree during a virtual ancestor mergeLibravatar Junio C Hamano1-1/+1
Fix another instance of a recursive merge incorrectly paying attention to the working tree file during a virtual ancestor merge, that resulted in spurious and useless "addinfo_cache failed" error message. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-21Remove 'working copy' from the documentation and C codeLibravatar Carlos Martín Nieto1-1/+1
The git term is 'working tree', so replace the most public references to 'working copy'. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-02Merge branch 'en/merge-recursive-2'Libravatar Junio C Hamano1-384/+695
* en/merge-recursive-2: (57 commits) merge-recursive: Don't re-sort a list whose order we depend upon merge-recursive: Fix virtual merge base for rename/rename(1to2)/add-dest t6036: criss-cross + rename/rename(1to2)/add-dest + simple modify merge-recursive: Avoid unnecessary file rewrites t6022: Additional tests checking for unnecessary updates of files merge-recursive: Fix spurious 'refusing to lose untracked file...' messages t6022: Add testcase for spurious "refusing to lose untracked" messages t3030: fix accidental success in symlink rename merge-recursive: Fix working copy handling for rename/rename/add/add merge-recursive: add handling for rename/rename/add-dest/add-dest merge-recursive: Have conflict_rename_delete reuse modify/delete code merge-recursive: Make modify/delete handling code reusable merge-recursive: Consider modifications in rename/rename(2to1) conflicts merge-recursive: Create function for merging with branchname:file markers merge-recursive: Record more data needed for merging with dual renames merge-recursive: Defer rename/rename(2to1) handling until process_entry merge-recursive: Small cleanups for conflict_rename_rename_1to2 merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base merge-recursive: Introduce a merge_file convenience function merge-recursive: Fix modify/delete resolution in the recursive case ...
2011-08-25Merge branch 'jn/plug-empty-tree-leak'Libravatar Junio C Hamano1-5/+3
* jn/plug-empty-tree-leak: merge-recursive: take advantage of hardcoded empty tree revert: plug memory leak in "cherry-pick root commit" codepath
2011-08-16merge-recursive: take advantage of hardcoded empty treeLibravatar Jonathan Nieder1-5/+3
When this code was first written (v1.4.3-rc1~174^2~4, merge-recur: if there is no common ancestor, fake empty one, 2006-08-09), everyone needing a fake empty tree had to make her own, but ever since v1.5.5-rc0~180^2~1 (2008-02-13), the object lookup machinery provides a ready-made one. Use it. This is just a simplification, though it also fixes a small leak (since the tree in the virtual common ancestor commit is never freed). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Don't re-sort a list whose order we depend uponLibravatar Elijah Newren1-4/+12
In record_df_conflict_files() we would resort the entries list using df_name_compare to get a convenient ordering. Unfortunately, this broke assumptions of the get_renames() code (via string_list_lookup() calls) which needed the list to be in the standard ordering. When those lookups would fail, duplicate stage_data entries could be inserted, causing the process_renames and process_entry code to fail (in particular, a path that that process_renames had marked as processed would still be processed anyway in process_entry due to the duplicate entry). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Fix virtual merge base for rename/rename(1to2)/add-destLibravatar Elijah Newren1-2/+21
Earlier in this series, the patch "merge-recursive: add handling for rename/rename/add-dest/add-dest" added code to handle the rename on each side of history also being involved in a rename/add conflict, but only did so in the non-recursive case. Add code for the recursive case, ensuring that the "added" files are not simply deleted. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Avoid unnecessary file rewritesLibravatar Elijah Newren1-6/+24
Often times, a potential conflict at a path is resolved by merge-recursive by using the content that was already present at that location. In such cases, we do not want to overwrite the content that is already present, as that could trigger unnecessary recompilations. One of the patches earlier in this series ("merge-recursive: When we detect we can skip an update, actually skip it") fixed the cases that involved content merges, but there were a few other cases as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Fix spurious 'refusing to lose untracked file...' messagesLibravatar Elijah Newren1-14/+20
Calling update_stages() before update_file() can sometimes result in git thinking the file being updated is untracked (whenever update_stages moves it to stage 3). Reverse the call order, and add a big comment to update_stages to hopefully prevent others from making the same mistake. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Fix working copy handling for rename/rename/add/addLibravatar Elijah Newren1-25/+48
If either side of a rename/rename(1to2) conflict is itself also involved in a rename/add-dest conflict, then we need to make sure both the rename and the added file appear in the working copy. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: add handling for rename/rename/add-dest/add-destLibravatar Elijah Newren1-2/+19
Each side of the rename in rename/rename(1to2) could potentially also be involved in a rename/add conflict. Ensure stages for such conflicts are also recorded. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Have conflict_rename_delete reuse modify/delete codeLibravatar Elijah Newren1-16/+30
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Make modify/delete handling code reusableLibravatar Elijah Newren1-34/+48
modify/delete and rename/delete share a lot of similarities; we'd like all the criss-cross and D/F conflict handling specializations to be shared between the two. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Consider modifications in rename/rename(2to1) conflictsLibravatar Elijah Newren1-9/+21
Our previous conflict resolution for renaming two different files to the same name ignored the fact that each of those files may have modifications from both sides of history to consider. We need to do a three-way merge for each of those files, and then handle the conflict of both sets of merged contents trying to be recorded with the same name. It is important to note that this changes our strategy in the recursive case. After doing a three-way content merge of each of the files involved, we still are faced with the fact that we are trying to put both of the results (including conflict markers) into the same path. We could do another two-way merge, but I think that becomes confusing. Also, taking a hint from the modify/delete and rename/delete cases we handled earlier, a more useful "common ground" would be to keep the three-way content merge but record it with the original filename. The renames can still be detected, we just allow it to be done in the o->call_depth=0 case. This seems to result in simpler & easier to understand merge conflicts as well, as evidenced by some of the changes needed in our testsuite in t6036. (However, it should be noted that this change will cause problems those renames also occur along with a file being added whose name matches the source of the rename. Since git currently cannot detect rename/add-source situations, though, this codepath is not currently used for those cases anyway. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Create function for merging with branchname:file markersLibravatar Elijah Newren1-9/+33
We want to be able to reuse the code to do a three-way file content merge and have the conflict markers use both branchname and filename. Split it out into a separate function. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Record more data needed for merging with dual renamesLibravatar Elijah Newren1-3/+39
When two different files are renamed to one, we need to be able to do three-way merges for both of those files. To do that, we need to record the sha1sum of the (possibly modified) file on the unrenamed side. Modify setup_rename_conflict_info() to take this extra information and record it when the rename_type is RENAME_TWO_FILES_TO_ONE. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Defer rename/rename(2to1) handling until process_entryLibravatar Elijah Newren1-42/+62
This puts the code for the different types of double rename conflicts closer together (fewer lines of other code separating the two paths) and increases similarity between how they are handled. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Small cleanups for conflict_rename_rename_1to2Libravatar Elijah Newren1-33/+27
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Fix rename/rename(1to2) resolution for virtual merge baseLibravatar Elijah Newren1-17/+13
When renaming one file to two files, we really should be doing a content merge. Also, in the recursive case, undoing the renames and recording the merged file in the index with the source of the rename (while deleting both destinations) allows the renames to be re-detected in the non-recursive merge and will result in fewer spurious conflicts. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Introduce a merge_file convenience functionLibravatar Elijah Newren1-35/+37
merge_file previously required diff_filespec arguments, but all callers only had sha1s and modes. Rename merge_file to merge_file_1 and introduce a new merge_file convenience function which takes the sha1s and modes and creates the temporary diff_filespec variables needed to call merge_file_1. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Fix modify/delete resolution in the recursive caseLibravatar Elijah Newren1-14/+24
When o->call_depth>0 and we have conflicts, we try to find "middle ground" when creating the virtual merge base. In the case of content conflicts, this can be done by doing a three-way content merge and using the result. In all parts where the three-way content merge is clean, it is the correct middle ground, and in parts where it conflicts there is no middle ground but the conflict markers provide a good compromise since they are unlikely to accidentally match any further changes. In the case of a modify/delete conflict, we cannot do the same thing. Accepting either endpoint as the resolution for the virtual merge base runs the risk that when handling the non-recursive case we will silently accept one person's resolution over another without flagging a conflict. In this case, the closest "middle ground" we have is actually the merge base of the candidate merge bases. (We could alternatively attempt a three way content merge using an empty file in place of the deleted file, but that seems to be more work than necessary.) Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: When we detect we can skip an update, actually skip itLibravatar Elijah Newren1-3/+16
In 882fd11 (merge-recursive: Delay content merging for renames 2010-09-20), there was code that checked for whether we could skip updating a file in the working directory, based on whether the merged version matched the current working copy. Due to the desire to handle directory/file conflicts that were resolvable, that commit deferred content merging by first updating the index with the unmerged entries and then moving the actual merging (along with the skip-the-content-update check) to another function that ran later in the merge process. As part moving the content merging code, a bug was introduced such that although the message about skipping the update would be printed (whenever GIT_MERGE_VERBOSITY was sufficiently high), the file would be unconditionally updated in the working copy anyway. When we detect that the file does not need to be updated in the working copy, update the index appropriately and then return early before updating the working copy. Note that there was a similar change in b2c8c0a (merge-recursive: When we detect we can skip an update, actually skip it 2011-02-28), but it was reverted by 6db4105 (Revert "Merge branch 'en/merge-recursive'" 2011-05-19) since it did not fix both of the relevant types of unnecessary update breakages and, worse, it made use of some band-aids that caused other problems. The reason this change works is due to the changes earlier in this series to (a) record_df_conflict_files instead of just unlinking them early, (b) allowing make_room_for_path() to remove D/F entries, (c) the splitting of update_stages_and_entry() to have its functionality called at different points, and (d) making the pathnames of the files involved in the merge available to merge_content(). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Provide more info in conflict markers with file renamesLibravatar Elijah Newren1-3/+25
Whenever there are merge conflicts in file contents, we would mark the different sides of the conflict with the two branches being merged. However, when there is a rename involved as well, the branchname is not sufficient to specify where the conflicting content came from. In such cases, mark the two sides of the conflict with branchname:filename rather than just branchname. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Cleanup and consolidation of rename_conflict_infoLibravatar Elijah Newren1-68/+66
The consolidation of process_entry() and process_df_entry() allows us to consolidate more code paths concerning rename conflicts, and to do a few additional related cleanups. It also means we are using rename_df_conflict_info in some cases where there is no D/F conflict; rename it to rename_conflict_info. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Consolidate process_entry() and process_df_entry()Libravatar Elijah Newren1-131/+57
The whole point of adding process_df_entry() was to ensure that files of D/F conflicts were processed after paths under the corresponding directory. However, given that the entries are in sorted order, all we need to do is iterate through them in reverse order to achieve the same effect. That lets us remove some duplicated code, and lets us keep track of one less thing as we read the code ("do we need to make sure this is processed before process_df_entry() or do we need to defer it until then?"). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Improve handling of rename target vs. directory additionLibravatar Elijah Newren1-5/+22
When dealing with file merging and renames and D/F conflicts and possible criss-cross merges (how's that for a corner case?), we did not do a thorough job ensuring the index and working directory had the correct contents. Fix the logic in merge_content() to handle this. Also, correct some erroneous tests in t6022 that were expecting the wrong number of unmerged index entries. These changes fix one of the tests in t6042 (and almost fix another one from t6042 as well). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Add comments about handling rename/add-source casesLibravatar Elijah Newren1-0/+11
There are a couple of places where changes are needed to for situations involving rename/add-source issues. Add comments about the needed changes (and existing bugs) until git has been enabled to detect such cases. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Make dead code for rename/rename(2to1) conflicts undeadLibravatar Elijah Newren1-22/+48
The code for rename_rename_2to1 conflicts (two files both being renamed to the same filename) was dead since the rename/add path was always being independently triggered for each of the renames instead. Further, reviving the dead code showed that it was inherently buggy and would always segfault -- among a few other bugs. Move the else-if branch for the rename/rename block before the rename/add block to make sure it is checked first, and fix up the rename/rename(2to1) code segments to make it handle most cases. Work is still needed to handle higher dimensional corner cases such as rename/rename/modify/modify issues. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Fix deletion of untracked file in rename/delete conflictsLibravatar Elijah Newren1-1/+2
In the recursive case (o->call_depth > 0), we do not modify the working directory. However, when o->call_depth==0, file renames can mean we need to delete the old filename from the working copy. Since there have been lots of changes and mistakes here, let's go through the details. Let's start with a simple explanation of what we are trying to achieve: Original goal: If a file is renamed on the side of history being merged into head, the filename serving as the source of that rename needs to be removed from the working directory. The path to getting the above statement implemented in merge-recursive took several steps. The relevant bits of code may be instructive to keep in mind for the explanation, especially since an English-only description involves double negatives that are hard to follow. These bits of code are: int remove_file(..., const char *path, int no_wd) { ... int update_working_directory = !o->call_depth && !no_wd; and remove_file(o, 1, ren1_src, <expression>); Where the choice for <expression> has morphed over time: 65ac6e9 (merge-recursive: adjust to loosened "working file clobbered" check 2006-10-27), introduced the "no_wd" parameter to remove_file() and used "1" for <expression>. This meant ren1_src was never deleted, leaving it around in the working copy. In 8371234 (Remove uncontested renamed files during merge. 2006-12-13), <expression> was changed to "index_only" (where index_only == !!o->call_depth; see b7fa51da). This was equivalent to using "0" for <expression> (due to the early logic in remove_file), and is orthogonal to the condition we actually want to check at this point; it resulted in the source file being removed except when index_only was false. This was problematic because the file could have been renamed on the side of history including head, in which case ren1_src could correspond to an untracked file that should not be deleted. In 183d797 (Keep untracked files not involved in a merge. 2007-02-04), <expression> was changed to "index_only || stage == 3". While this gives correct behavior, the "index_only ||" portion of <expression> is unnecessary and makes the code slightly harder to follow. There were also two further changes to this expression, though without any change in behavior. First in b7fa51d (merge-recursive: get rid of the index_only global variable 2008-09-02), it was changed to "o->call_depth || stage == 3". (index_only == !!o->call_depth). Later, in 41d70bd6 (merge-recursive: Small code clarification -- variable name and comments), this was changed to "o->call_depth || renamed_stage == 2" (where stage was renamed to other_stage and renamed_stage == other_stage ^ 1). So we ended with <expression> being "o->call_depth || renamed_stage == 2". But the "o->call_depth ||" piece was unnecessary. We can remove it, leaving us with <expression> being "renamed_stage == 2". This doesn't change behavior at all, but it makes the code clearer. Which is good, because it's about to get uglier. Corrected goal: If a file is renamed on the side of history being merged into head, the filename serving as the source of that rename needs to be removed from the working directory *IF* that file is tracked in head AND the file tracked in head is related to the original file. Note that the only difference between the original goal and the corrected goal is the two extra conditions added at the end. The first condition is relevant in a rename/delete conflict. If the file was deleted on the HEAD side of the merge and an untracked file of the same name was added to the working copy, then without that extra condition the untracked file will be erroneously deleted. This changes <expression> to "renamed_stage == 2 || !was_tracked(ren1_src)". The second additional condition is relevant in two cases. The first case the second condition can occur is when a file is deleted and a completely different file is added with the same name. To my knowledge, merge-recursive has no mechanism for detecting deleted-and- replaced-by-different-file cases, so I am simply punting on this possibility. The second case for the second condition to occur is when there is a rename/rename/add-source conflict. That is, when the original file was renamed on both sides of history AND the original filename is being re-used by some unrelated (but tracked) content. This case also presents some additional difficulties for us since we cannot currently detect these rename/rename/add-source conflicts; as long as the rename detection logic "optimizes" by ignoring filenames that are present at both ends of the diff, these conflicts will go unnoticed. However, rename/rename conflicts are handled by an entirely separate codepath not being discussed here, so this case is not relevant for the line of code under consideration. In summary: Change <expression> from "o->call_depth || renamed_stage == 2" to "renamed_stage == 2 || !was_tracked(ren1_src)", in order to remove unnecessary code and avoid deleting untracked files. 96 lines of explanation in the changelog to describe a one-line fix... Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>