aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* 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>
* t6022: New test checking for unnecessary updates of files in D/F conflictsElijah Newren2011-03-02
| | | | | | Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6022: New test checking for unnecessary updates of renamed+modified filesElijah Newren2011-03-02
| | | | | Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6022: Use -eq not = to test output of wc -lBrian Gernhardt2010-11-17
| | | | | | | | | When comparing numbers such as "3" to "$(wc -l)", we should check for numerical equality using -eq instead of string equality using = because some implementations of wc output extra whitespace. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 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>
* t6036: Add testcase for undetected conflictElijah Newren2010-09-29
| | | | | | | | | | | | | If merging two lines of development involves a rename/add conflict, and two different people make such a merge but resolve it differently, and then someone tries to merge the resulting two merges, then they should clearly get a conflict due to the different resolutions from the previous developers. However, in some such cases the conflict would not be detected and git would silently accept one of the two versions being merged as the final merge resolution. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6036: Add a second testcase similar to the first but with content changesElijah Newren2010-09-29
| | | | | | | | | | | c94736a (merge-recursive: don't segfault while handling rename clashes 2009-07-30) added t6036 with a testcase that involved dual renames and a criss-cross merge. Add a test that is nearly identical, but which also involves content modification -- a case git currently does not merge correctly. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6036: Test index and worktree state, not just that merge failsElijah Newren2010-09-29
| | | | | | | | | | | | c94736a (merge-recursive: don't segfault while handling rename clashes 2009-07-30) added this testcase with an interesting corner case test, which previously had cased git to segfault. This test ensures that the segfault does not return and that the merge correctly fails; just add some checks that verify the state of the index and worktree after the merge are correct. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6020: Add a testcase for modify/delete + directory/file conflictElijah Newren2010-09-29
| | | | | Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6020: Modernize style a bitElijah Newren2010-09-29
| | | | | Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6022: Add tests for rename/rename combined with D/F conflictsElijah Newren2010-09-29
| | | | | | | | | | | Add tests where one file is renamed to two different paths in different sides of history, and where each of the new files matches the name of a directory from the opposite side of history. Include tests for both the case where the merge results in those directories not being cleanly removed, and where those directories are cleanly removed during the merge. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6022: Add paired rename+D/F conflict: (two/file, one/file) -> (one, two)Elijah Newren2010-09-29
| | | | | | | | | | | An interesting testcase is having two files each in their own subdirectory getting renamed to the toplevel at the directory pathname of the other. Questions arise as to whether the order of operations matters and whether the directories can correctly get out of the way and make room for the new files. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6022: Add tests with both rename source & dest involved in D/F conflictsElijah Newren2010-09-29
| | | | | | | | | | | Having the source of a rename be involved in a directory/file conflict does not currently pose any difficulties to the current merge-recursive algorithm (in contrast to destinations of renames and D/F conflicts). However, combining the two seemed like good testcases to include for completeness. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6022: Add tests for reversing order of merges when D/F conflicts presentElijah Newren2010-09-29
| | | | | | | | | | | | | | | | | When merging two branches with some path involved in a D/F conflict, the choice of which branch to merge into the other matters for (at least) two reasons: (1) whether the working copy has a directory full of files that is in the way of a file, or a file exists that is in the way of a directory of files, (2) when the directory full of files does not disappear due to the merge, what files at the same paths should be renamed to (e.g. filename~HEAD vs. filename~otherbranch). Add some tests that reverse the merge order of two other tests, and which verify the contents are as expected (namely, that the results are identical other than modified-for-uniqueness filenames involving branch names). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6022: Add test combinations of {content conflict?, D/F conflict remains?}Elijah Newren2010-09-29
| | | | | | | | | | | Add testing of the various ways that a renamed file to a path involved in a directory/file conflict may be involved in. This includes whether or not there are conflicts of the contents of the renamed file (if the file was modified on both sides of history), and whether the directory from the other side of the merge will disappear as a result of the merge or not. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t6032: Add a test checking for excessive output from mergeElijah Newren2010-09-29
| | | | | | | | | | Previous D/F fixes I submitted (5a2580d and ae74548) had caused merge to become excessively spammy, which was fixed in 96ecac6 (merge-recursive: Avoid excessive output for and reprocessing of renames 2010-08-20). Add a new test to avoid repeating that mistake with my several upcoming changes. 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>
* t3030: Add a testcase for resolvable rename/add conflict with symlinksSchalk, Ken2010-09-29
| | | | | | | | | | | | d5af510 (RE: [PATCH] Avoid rename/add conflict when contents are identical 2010-09-01) avoided erroring out in a rename/add conflict when the contents were identical. A simpler fix could have handled that particular testcase, but it would not correctly handle the case where a symlink is involved. Add another testcase using symlinks, to avoid breaking that case. Signed-off-by: Ken Schalk <ken.schalk@intel.com> 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>
| * t3509: Add rename + D/F conflict testcase that recursive strategy failsElijah Newren2010-09-09
| | | | | | | | | | | | | | | | | | When one side of a file rename matches a directory name on the other side, the recursive merge strategy will fail. This is true even if the merge is trivially resolvable. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Git 1.7.3v1.7.3Junio C Hamano2010-09-18
| | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'js/ls-files-x-doc'Junio C Hamano2010-09-18
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | * js/ls-files-x-doc: ls-files documentation: reword for consistency git-ls-files.txt: clarify -x/--exclude option Conflicts: Documentation/git-ls-files.txt
| * | ls-files documentation: reword for consistencyJunio C Hamano2010-09-15
| | | | | | | | | | | | | | | | | | | | | | | | Similar to descriptions of other options, state what -x does in imperative mood. Start sentences for -X and --exclude-per-directory options in capital letters. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | git-ls-files.txt: clarify -x/--exclude optionJay Soffian2010-09-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since b5227d8, -x/--exclude does not apply to cached files. This is easy to miss unless you read the discussion in the EXCLUDE PATTERNS section. Clarify that the option applies to untracked files and direct the reader to EXCLUDE PATTERNS. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-10-02 02:56:58 +0000