aboutsummaryrefslogtreecommitdiff
path: root/merge-recursive.c
Commit message (Collapse)AuthorAge
* teach --histogram to diffTay Ray Chuan2011-07-12
| | | | | | | | | | | | | | | Port JGit's HistogramDiff algorithm over to C. Rough numbers (TODO) show that it is faster than its --patience cousin, as well as the default Meyers algorithm. The implementation has been reworked to use structs and pointers, instead of bitmasks, thus doing away with JGit's 2^28 line limit. We also use xdiff's default hash table implementation (xdl_hash_bits() with XDL_HASHLONG()) for convenience. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Revert "Merge branch 'en/merge-recursive'"Junio C Hamano2011-05-19
| | | | | | | | As the band-aid to merge-recursive seems to regress complex merges in an unpleasant way. The merge-recursive implementation needs to be rewritten in such a way that it resolves renames and D/F conflicts entirely in-core and not to touch working tree at all while doing so. But in the meantime, this reverts commit ac9666f84 that merged the topic in its entirety.
* Merge branch 'maint'Junio C Hamano2011-05-14
|\ | | | | | | | | * maint: add, merge, diff: do not use strcasecmp to compare config variable names
| * add, merge, diff: do not use strcasecmp to compare config variable namesJonathan Nieder2011-05-14
| | | | | | | | | | | | | | | | | | | | The config machinery already makes section and variable names lowercase when parsing them, so using strcasecmp for comparison just feels wasteful. No noticeable change intended. Noticed-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'nd/struct-pathspec'Junio C Hamano2011-05-06
|\ \ | | | | | | | | | | | | | | | | | | | | | * nd/struct-pathspec: pathspec: rename per-item field has_wildcard to use_wildcard Improve tree_entry_interesting() handling code Convert read_tree{,_recursive} to support struct pathspec Reimplement read_tree_recursive() using tree_entry_interesting()
| * | Convert read_tree{,_recursive} to support struct pathspecNguyễn Thái Ngọc Duy2011-03-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes behavior of the two functions. Previously it does prefix matching only. Now it can also do wildcard matching. All callers are updated. Some gain wildcard matching (archive, checkout), others reset pathspec_item.has_wildcard to retain old behavior (ls-files, ls-tree as they are plumbing). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jc/rename-degrade-cc-to-c'Junio C Hamano2011-04-28
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jc/rename-degrade-cc-to-c: diffcore-rename: fall back to -C when -C -C busts the rename limit diffcore-rename: record filepair for rename src diffcore-rename: refactor "too many candidates" logic builtin/diff.c: remove duplicated call to diff_result_code()
| * | | diffcore-rename: fall back to -C when -C -C busts the rename limitJunio C Hamano2011-03-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When there are too many paths in the project, the number of rename source candidates "git diff -C -C" finds will exceed the rename detection limit, and no inexact rename detection is performed. We however could fall back to "git diff -C" if the number of modified paths is sufficiently small. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'en/merge-recursive'Junio C Hamano2011-04-28
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | * en/merge-recursive: merge-recursive: tweak magic band-aid merge-recursive: When we detect we can skip an update, actually skip it t6022: New test checking for unnecessary updates of files in D/F conflicts t6022: New test checking for unnecessary updates of renamed+modified files
| * | | merge-recursive: tweak magic band-aidJunio C Hamano2011-03-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Running checks against working tree (e.g. lstat()) and causing changes to working tree (e.g. unlink()) while building a virtual ancestor merge does not make any sense. Avoid doing so. This is not a real fix; it is another magic band-aid on top of another band-aid we placed earlier. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | merge-recursive: When we detect we can skip an update, actually skip itElijah Newren2011-03-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Fix two unused variable warnings in gcc 4.6Dan McGee2011-04-03
| |/ / |/| | | | | | | | | | | | | | | | | Seen with -Wunused-but-set-variable. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jk/merge-rename-ux'Junio C Hamano2011-03-19
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jk/merge-rename-ux: pull: propagate --progress to merge merge: enable progress reporting for rename detection add inexact rename detection progress infrastructure commit: stop setting rename limit bump rename limit defaults (again) merge: improve inexact rename limit warning
| * | | merge: enable progress reporting for rename detectionJeff King2011-02-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The user can enable or disable it explicitly with the new --progress, but it defaults to checking isatty(2). This works only with merge-recursive and subtree. In theory we could pass a progress flag to other strategies, but none of them support progress at this point, so let's wait until they grow such a feature before worrying about propagating it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | bump rename limit defaults (again)Jeff King2011-02-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We did this once before in 5070591 (bump rename limit defaults, 2008-04-30). Back then, we were shooting for about 1 second for a diff/log calculation, and 5 seconds for a merge. There are a few new things to consider, though: 1. Average processors are faster now. 2. We've seen on the mailing list some ugly merges where not using inexact rename detection leads to many more conflicts. Merges of this size take a long time anyway, so users are probably happy to spend a little bit of time computing the renames. Let's bump the diff/merge default limits from 200/500 to 400/1000. Those are 2 seconds and 10 seconds respectively on my modern hardware. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | merge: improve inexact rename limit warningJeff King2011-02-21
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The warning is generated deep in the diffcore code, which means that it will come first, followed possibly by a spew of conflicts, making it hard to see. Instead, let's have diffcore pass back the information about how big the rename limit would needed to have been, and then the caller can provide a more appropriate message (and at a more appropriate time). No refactoring of other non-merge callers is necessary, because nobody else was even using the warn_on_rename_limit feature. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'maint'Junio C Hamano2011-03-16
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: Prepare draft release notes to 1.7.4.2 gitweb: highlight: replace tabs with spaces make_absolute_path: return the input path if it points to our buffer valgrind: ignore SSE-based strlen invalid reads diff --submodule: split into bite-sized pieces cherry: split off function to print output lines branch: split off function that writes tracking info and commit subject standardize brace placement in struct definitions compat: make gcc bswap an inline function enums: omit trailing comma for portability Conflicts: RelNotes
| * | | standardize brace placement in struct definitionsJonathan Nieder2011-03-16
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a struct definitions, unlike functions, the prevailing style is for the opening brace to go on the same line as the struct name, like so: struct foo { int bar; char *baz; }; Indeed, grepping for 'struct [a-z_]* {$' yields about 5 times as many matches as 'struct [a-z_]*$'. Linus sayeth: Heretic people all over the world have claimed that this inconsistency is ... well ... inconsistent, but all right-thinking people know that (a) K&R are _right_ and (b) K&R are right. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | strbuf: add strbuf_vaddfJeff King2011-02-26
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a variable-args function, the code for writing into a strbuf is non-trivial. We ended up cutting and pasting it in several places because there was no vprintf-style function for strbufs (which in turn was held up by a lack of va_copy). Now that we have a fallback va_copy, we can add strbuf_vaddf, the strbuf equivalent of vsprintf. And we can clean up the cut and paste mess. Signed-off-by: Jeff King <peff@peff.net> Improved-by: Christian Couder <christian.couder@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'en/merge-recursive'Junio C Hamano2010-11-29
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * en/merge-recursive: (41 commits) t6022: Use -eq not = to test output of wc -l merge-recursive:make_room_for_directories - work around dumb compilers merge-recursive: Remove redundant path clearing for D/F conflicts merge-recursive: Make room for directories in D/F conflicts handle_delete_modify(): Check whether D/F conflicts are still present merge_content(): Check whether D/F conflicts are still present conflict_rename_rename_1to2(): Fix checks for presence of D/F conflicts conflict_rename_delete(): Check whether D/F conflicts are still present merge-recursive: Delay modify/delete conflicts if D/F conflict present merge-recursive: Delay content merging for renames merge-recursive: Delay handling of rename/delete conflicts merge-recursive: Move handling of double rename of one file to other file merge-recursive: Move handling of double rename of one file to two merge-recursive: Avoid doubly merging rename/add conflict contents merge-recursive: Update merge_content() call signature merge-recursive: Update conflict_rename_rename_1to2() call signature merge-recursive: Structure process_df_entry() to handle more cases merge-recursive: Have process_entry() skip D/F or rename entries merge-recursive: New function to assist resolving renames in-core only merge-recursive: New data structures for deferring of D/F conflicts ... Conflicts: t/t6020-merge-df.sh t/t6036-recursive-corner-cases.sh
| * merge-recursive:make_room_for_directories - work around dumb compilersJunio C Hamano2010-10-21
| | | | | | | | | | | | | | | | | | | | Some vintage of gcc does not seem to notice last_len is only used when last_file is already set to non-NULL at which point last_len is also set. Noticed on FreeBSD 8 Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Remove redundant path clearing for D/F conflictsElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code had several places where individual checks were done to remove files that could be in the way of directories in D/F conflicts. Not all D/F conflicts could have a path cleared for them in such a manner, however, leading to the need to create make_room_for_directories_of_df_conflicts() as done in the previous patch. That new function could not have been incorporated into the code sooner, since not all relevant code paths had been deferred to process_df_entry() yet, leading to the creation of even more of these now-redundant path removals. Clean out all of these extra D/F path clearing cases. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Make room for directories in D/F conflictsElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | | | | | | | | | When there are unmerged entries present, make sure to check for D/F conflicts first and remove any files present in HEAD that would be in the way of creating files below the correspondingly named directory. Such files will be processed again at the end of the merge in process_df_entry(); at that time we will be able to tell if we need to and can reinstate the file, whether we need to place its contents in a different file due to the directory still being present, etc. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * handle_delete_modify(): Check whether D/F conflicts are still presentElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | If all the paths below some directory involved in a D/F conflict were not removed during the rest of the merge, then the contents of the file whose path conflicted needs to be recorded in file with an alternative filename. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge_content(): Check whether D/F conflicts are still presentElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | If all the paths below some directory involved in a D/F conflict were not removed during the rest of the merge, then the contents of the file whose path conflicted needs to be recorded in file with an alternative filename. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * conflict_rename_rename_1to2(): Fix checks for presence of D/F conflictsElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | | | This function is called from process_df_entry(), near the end of the merge. Rather than just checking whether one of the sides of the merge had a directory at the same path as one of our files, check whether that directory is still present by this point of our merge. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * conflict_rename_delete(): Check whether D/F conflicts are still presentElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | If all the paths below some directory involved in a D/F conflict were not removed during the rest of the merge, then the contents of the file whose path conflicted needs to be recorded in file with an alternative filename. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Delay modify/delete conflicts if D/F conflict presentElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | When handling merges with modify/delete conflicts, if the modified path is involved in a D/F conflict, handle the issue in process_df_entry() rather than process_entry(). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Delay content merging for renamesElijah Newren2010-09-29
| | | | | | | | | | | | | | | | Move the handling of content merging for renames from process_renames() to process_df_entry(). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Delay handling of rename/delete conflictsElijah Newren2010-09-29
| | | | | | | | | | | | | | | | Move the handling of rename/delete conflicts from process_renames() to process_df_entry(). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Move handling of double rename of one file to other fileElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | | | | | | | Move the handling of rename/rename conflicts where one file is renamed on both sides to the same file, from process_renames() to process_entry(). Here we avoid the three way merge logic by just using update_stages_and_entry() to move the higher stage entries in the index from the rename source to the rename destination, and then allow process_entry() to do its magic. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Move handling of double rename of one file to twoElijah Newren2010-09-29
| | | | | | | | | | | | | | | | Move the handling of rename/rename conflicts where one file is renamed to two different files, from process_renames() to process_df_entry(). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Avoid doubly merging rename/add conflict contentsElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a commit moves A to B while another commit created B (or moved C to B), and these two different commits serve as different merge-bases for a later merge, c94736a (merge-recursive: don't segfault while handling rename clashes 2009-07-30) added some special code to avoid segfaults. Since that commit, the two versions of B are merged in place (which could be potentially conflicting) and the intermediate result is used as the virtual ancestor. However, right before this special merge, try_merge was turned on, meaning that process_renames() would try an alternative merge that ignores the 'add' part of the conflict, and, if the merge is clean, store that as the new virtual ancestor. This could cause incorrect merging of criss-cross merges; it would typically result in just recording a slightly confusing merge base, but in some cases it could cause silent acceptance of one side of a merge as the final resolution when a conflict should have been flagged. When we do a special merge for such a rename/add conflict between merge-bases, turn try_merge off to avoid an inappropriate second merge. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Update merge_content() call signatureElijah Newren2010-09-29
| | | | | | | | | | | | | | | | Enable calling merge_content() and providing more information about renames and D/F conflicts (which we will want to do from process_df_entry()). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Update conflict_rename_rename_1to2() call signatureElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | To facilitate having this function called later using information stored in a rename_df_conflict_info struct, accept a diff_filepair instead of a rename. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Structure process_df_entry() to handle more casesElijah Newren2010-09-29
| | | | | | | | | | | | | | | | Modify process_df_entry() (mostly just indentation level changes) to get it ready for handling more D/F conflict type cases. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Have process_entry() skip D/F or rename entriesElijah Newren2010-09-29
| | | | | | | | | | | | | | | | If an entry has an associated rename_df_conflict_info, skip it and allow it to be processed by process_df_entry(). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: New function to assist resolving renames in-core onlyElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | process_renames() and process_entry() have nearly identical code for doing three-way file merging to resolve content changes. Since we are already deferring some of the current rename handling in order to better handle D/F conflicts, it seems to make sense to defer content merging as well and remove the (nearly) duplicated code sections for handling this merging. To facilitate this process, add a new update_stages_and_entry() function which will map the higher stage index entries from two files involved in a rename into the resulting rename destination's index entries, and update the associated stage_data structure. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: New data structures for deferring of D/F conflictsElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we need to resolve paths (including renames) in-core first and defer checking of D/F conflicts (namely waiting to see if directories are still in the way after all paths are resolved) before updating files involved in D/F conflicts, we will need to first process_renames, then record some information about the rename needed at D/F resolution time, and then make use of that information when resolving D/F conflicts at the end. This commit adds some relevant data structures for storing the necessary information. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Move process_entry's content merging into a functionElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | | | | | | | | | This move is in preparation for merge_content growing and being called from multiple places in order to handle D/F conflicts. I also snuck in a small change to the output in the case that the merged content for the file matches the current file contents, to make it better match (and thus more able to take over) how other merge_file() calls in process_renames() are handled. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Move delete/modify handling into dedicated functionElijah Newren2010-09-29
| | | | | | | | | | | | | | | | This move is in preparation for the function being called from multiple places in order to handle D/F conflicts. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Move rename/delete handling into dedicated functionElijah Newren2010-09-29
| | | | | | | | | | | | | | | | This move is in preparation for the function growing and being called from multiple places in order to handle D/F conflicts. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Nuke rename/directory conflict detectionElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | Since we want to resolve merges in-core and then detect at the end whether D/F conflicts remain in the way, we should just apply renames in-core and let logic elsewhere check for D/F conflicts. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Rename conflict_rename_rename*() for clarityElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | | | | | | | The names conflict_rename_rename and conflict_rename_rename_2 did not make it clear what they were handling. Since the first of these handles one file being renamed in both branches to different files, while the latter handles two different files being renamed to the same thing, add a little '1to2' and '2to1' suffix on these and an explanatory comment to make their intent clearer. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Small code clarification -- variable name and commentsElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | | | | | | process_renames() had a variable named "stage" and derived variables src_other and dst_other whose purpose was not immediately obvious; also, I want to extend the scope of this variable and use it later, so it should have a more descriptive name. Do so, and add a brief comment explaining how it is used and what it relates to. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * merge-recursive: Restructure showing how to chain more process_* functionsJunio C Hamano2010-09-29
| | | | | | | | | | | | | | | | | | | | | | In 3734893 (merge-recursive: Fix D/F conflicts 2010-07-09), process_df_entry() was added to process_renames() and process_entry() but in a somewhat restrictive manner. Modify the code slightly to make it clearer how we could chain more such functions if necessary, and alter process_df_entry() to handle such chaining. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Merge branch 'en/rename-d-f' into en/merge-recursiveJunio C Hamano2010-09-29
| |\ | | | | | | | | | | | | | | | * en/rename-d-f: merge-recursive: D/F conflicts where was_a_dir/file -> was_a_dir t3509: Add rename + D/F conflict testcase that recursive strategy fails
| | * merge-recursive: D/F conflicts where was_a_dir/file -> was_a_dirElijah Newren2010-09-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In merge-recursive.c, whenever there was a rename where a file name on one side of the rename matches a directory name on the other side of the merge, then the very first check that string_list_has_string(&o->current_directory_set, ren1_dst) would trigger forcing it into marking it as a rename/directory conflict. However, if the path is only renamed on one side and a simple three-way merge between the separate files resolves cleanly, then we don't need to mark it as a rename/directory conflict. So, we can simply move the check for rename/directory conflicts after we've verified that there isn't a rename/rename conflict and that a threeway content merge doesn't work. This changes the particular error message one gets in the case where the directory name that a file on one side of the rename matches is not also part of the rename pair. For example, with commits containing the files: COMMON -> (HEAD, MERGE ) --------- --------------- ------- sub/file1 -> (sub/file1, newsub) <NULL> -> (newsub/newfile, <NULL>) then previously when one tried to merge MERGE into HEAD, one would get CONFLICT (rename/directory): Rename sub/file1->newsub in HEAD directory newsub added in merge Renaming sub/file1 to newsub~HEAD instead Adding newsub/newfile Automatic merge failed; fix conflicts and then commit the result. After this patch, the error message will instead become: Removing newsub Adding newsub/newfile CONFLICT (file/directory): There is a directory with name newsub in merge. Adding newsub as newsub~HEAD Automatic merge failed; fix conflicts and then commit the result. That makes more sense to me, because git can't know that there's a conflict until after it's tried resolving paths involving newsub/newfile to see if they are still in the way at the end (and if newsub/newfile is not in the way at the end, there should be no conflict at all, which did not hold with git previously). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'kb/merge-recursive-rename-threshold'Junio C Hamano2010-10-26
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * kb/merge-recursive-rename-threshold: diff: add synonyms for -M, -C, -B merge-recursive: option to specify rename threshold Conflicts: Documentation/diff-options.txt Documentation/merge-strategies.txt
| * | | merge-recursive: option to specify rename thresholdKevin Ballard2010-09-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The recursive merge strategy turns on rename detection but leaves the rename threshold at the default. Add a strategy option to allow the user to specify a rename threshold to use. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-13 09:59:19 +0000