summaryrefslogtreecommitdiff
path: root/t/t3030-merge-recursive.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-08-13merge-recursive: fix verbose output for multiple base treesLibravatar René Scharfe1-0/+18
One of the indirect callers of make_virtual_commit() passes the result of oid_to_hex() as the name, i.e. a pointer to a static buffer. Since the function uses that string pointer directly in building a struct merge_remote_desc, multiple entries can end up sharing the same name inadvertently. Fix that by calling set_merge_remote_desc(), which creates a copy of the string, instead of building the struct by hand. Signed-off-by: Rene Scharfe <l.s.r@web.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-27t/t3030-merge-recursive.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-1/+1
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-26t6031: move triple-rename test to t3030Libravatar Jeff King1-0/+30
The t6031 test was introduced to check filemode handling of merge-recursive. Much later, an unrelated test was tacked on to look at renames and d/f conflicts. This test does not depend on anything that happened before (it actually blows away any existing content in the test repo). Let's move it to t3030, where there are more related tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24merge-recursive.c: tolerate missing files while refreshing indexLibravatar Brad King1-1/+1
Teach add_cacheinfo to tell make_cache_entry to skip refreshing stat information when a file is missing from the work tree. We do not want the index to be stat-dirty after the merge but also do not want to fail when a file happens to be missing. This fixes the 'merge-recursive w/ empty work tree - ours has rename' case in t3030-merge-recursive. Suggested-by: Elijah Newren <newren@gmail.com> Signed-off-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24t3030-merge-recursive: test known breakage with empty work treeLibravatar Brad King1-0/+47
Sometimes when working with a large repository it can be useful to try out a merge and only check out conflicting files to disk (for example as a speed optimization on a server). Until v1.7.7-rc1~28^2~20 (merge-recursive: When we detect we can skip an update, actually skip it, 2011-08-11), it was possible to do so with the following idiom: # Prepare a temporary index and empty work tree. GIT_INDEX_FILE="$PWD/tmp-$$-index" && export GIT_INDEX_FILE && GIT_WORK_TREE="$PWD/tmp-$$-work" && export GIT_WORK_TREE && mkdir "$GIT_WORK_TREE" && # Convince the index that our side is on disk. git read-tree -i -m $ours && git update-index --ignore-missing --refresh && # Merge their side into our side. bases=$(git merge-base --all $ours $theirs) && git merge-recursive $bases -- $ours $theirs && tree=$(git write-tree) Nowadays, that still works and the exit status is the same, but merge-recursive produces a diagnostic if "our" side renamed a file: error: addinfo_cache failed for path 'dst' Add a test to document this regression. Signed-off-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07t3030: use test_ln_s_add to remove SYMLINKS prerequisiteLibravatar Johannes Sixt1-36/+26
The test cases include many corner-cases of merge-recursive's behavior, some of them involve type changes and symbolic links. All cases, including those that are protected by SYMLINKS check only whether the result of merge-recursive is correctly stored in the database and the index; the file system is not investigated. Use test_ln_s_add to enter a symbolic link in the index in the test setup and run the tests without the SYMLINKS prerequisite. Notice that one test that has the SYMLINKS protection removed is an expect_failure. There is a possibility that the test fails differently depending on whether SYMLINKS is present or not; but this is not the case presently. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09t3030 (merge-recursive): use test_expect_codeLibravatar Ramkumar Ramachandra1-66/+6
Use test_expect_code in preference to repeatedly checking exit codes by hand. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14t3030: fix accidental success in symlink renameLibravatar Jeff King1-2/+5
In this test, we have merge two branches. On one branch, we renamed "a" to "e". On the other, we renamed "a" to "e" and then added a symlink pointing at "a" pointing to "e". The results for the test indicate that the merge should succeed, but also that "a" should no longer exist. Since both sides renamed "a" to the same destination, we will end up comparing those destinations for content. But what about what's left? One side (the rename only), replaced "a" with nothing. The other side replaced it with a symlink. The common base must also be nothing, because any "a" before this was meaningless (it was totally unrelated content that ended up getting renamed). The only sensible resolution is to keep the symlink. The rename-only side didn't touch the content versus the common base, and the other side added content. The 3-way merge dictates that we take the side with a change. And this gives the overall merge an intuitive result. One side made one change (a rename), and the other side made two changes: an identical rename, and an addition (that just happened to be at the same spot). The end result should contain both changes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13i18n: use test_i18ngrep in t2020, t2204, t3030, and t3200Libravatar Junio C Hamano1-4/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-merge "You have not concluded your merge" messagesLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Gettextize the "You have not concluded your merge messages. A test in t3030-merge-recursive.sh explicitly checked for this message. Change it to skip the test under GETTEXT_POISON=YesPlease. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-29Merge branch 'en/merge-recursive'Libravatar Junio C Hamano1-1/+36
* 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
2010-11-09tests: add missing &&Libravatar Jonathan Nieder1-1/+1
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29t3030: Add a testcase for resolvable rename/add conflict with symlinksLibravatar Schalk, Ken1-1/+36
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>
2010-09-15Merge branch 'ks/recursive-rename-add-identical'Libravatar Junio C Hamano1-0/+35
* ks/recursive-rename-add-identical: RE: [PATCH] Avoid rename/add conflict when contents are identical
2010-09-03RE: [PATCH] Avoid rename/add conflict when contents are identicalLibravatar Schalk, Ken1-0/+35
>Due to this this (and maybe all the tests) need to depend on the >SYMLINKS prereq. Here's a third attempt with no use of symlinks in the test: Skip the entire rename/add conflict case if the file added on the other branch has the same contents as the file being renamed. This avoids giving the user an extra copy of the same file and presenting a conflict that is confusing and pointless. A simple test of this case has been added in t/t3030-merge-recursive.sh. Signed-off-by: Ken Schalk <ken.schalk@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-11unpack_trees: group error messages by typeLibravatar Matthieu Moy1-1/+1
When an error is encountered, it calls add_rejected_file() which either - directly displays the error message and stops if in plumbing mode (i.e. if show_all_errors is not initialized at 1) - or stores it so that it will be displayed at the end with display_error_msgs(), Storing the files by error type permits to have a list of files for which there is the same error instead of having a serie of almost identical errors. As each bind_overlap error combines a file and an old file, a list cannot be done, therefore, theses errors are not stored but directly displayed. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-11merge-recursive: demonstrate an incorrect conflict with submoduleLibravatar Johannes Sixt1-0/+29
When one side of a merge turns a directory into a submodule, and the other side does not touch that directory (but has other non-conflicting changes), then a merge should succeed. But currently, it does not; it rather fails with a file/directory conflict. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-12Be more user-friendly when refusing to do something because of conflict.Libravatar Matthieu Moy1-2/+4
Various commands refuse to run in the presence of conflicts (commit, merge, pull, cherry-pick/revert). They all used to provide rough, and inconsistant error messages. A new variable advice.resolveconflict is introduced, and allows more verbose messages, pointing the user to the appropriate solution. For commit, the error message used to look like this: $ git commit foo.txt: needs merge foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169) foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030) foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4) error: Error building trees The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN option to make the output more consistant with the other porcelain commands, and catch the error in return, to stop with a clean error message. The next lines were displayed by a call to cache_tree_update(), which is not reached anymore if we noticed the conflict. The new output looks like: U foo.txt fatal: 'commit' is not possible because you have unmerged files. Please, fix them up in the work tree, and then use 'git add/rm <file>' as appropriate to mark resolution and make a commit, or use 'git commit -a'. Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD exists instead of waiting for merge to complain. The behavior of merge and the test-case are slightly modified to reflect the usual flow: start with conflicts, fix them, and afterwards get rid of MERGE_HEAD, with different error messages at each stage. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-01refuse to merge during a mergeLibravatar Clemens Buchacher1-0/+3
The following is an easy mistake to make for users coming from version control systems with an "update and commit"-style workflow. 1. git pull 2. resolve conflicts 3. git pull Step 3 overrides MERGE_HEAD, starting a new merge with dirty index. IOW, probably not what the user intended. Instead, refuse to merge again if a merge is in progress. Reported-by: Dave Olszewski <cxreg@pobox.com> Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-26Remove empty directories in recursive mergeLibravatar Alex Riesen1-0/+11
The code was actually supposed to do that, but was accidentally broken. Noticed by Anders Melchiorsen. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-03tests: use "git xyzzy" form (t0000 - t3599)Libravatar Nanako Shiraishi1-7/+7
Converts tests between t0050-t3903. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-23merge: fix numerus bugs around "trivial merge" areaLibravatar Junio C Hamano1-0/+11
The "trivial merge" codepath wants to optimize itself by making an internal call to the read-tree machinery, but it does not read the index before doing so, and the codepath is never exercised. Incidentally, this failure to read the index upfront means that the safety to refuse doing anything when the index is unmerged does not kick in, either. These two problem are fixed by using read_cache_unmerged() that does read the index before checking if it is unmerged at the beginning of cmd_merge(). The primary logic of the merge, however, assumes that the process never reads the index in-core, and the call to write_cache_as_tree() it makes from write_tree_trivial() will always read from the on-disk index that is prepared the strategy back-ends. This assumption is now broken by the above fix. To fix this issue, we now call discard_cache() before calling write_tree_trivial() when it wants to write the on-disk index as a tree. When multiple strategies are tried, their results are evaluated by reading the resulting index and inspecting it. The codepath needs to make a call to read_cache() for each successful strategy, and for that to work, they need to discard_cache() the one read by the previous round. Also the "trivial merge" forgot that the current commit is one of the parents of the resulting commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24tests: do not use implicit "git diff --no-index"Libravatar Junio C Hamano1-21/+21
As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+0
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-19Remove case-sensitive file in t3030-merge-recursive.Libravatar Brian Gernhardt1-52/+52
Rename "A" to the unused "c" Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-10t3030: merge-recursive backend test.Libravatar Junio C Hamano1-0/+528
We have fairly extensive coverage of read-tree 3-way machinery, and many Porcelain-ish tests use git-merge front-end tests, but we did not have good basic test for merge-recursive, which made it very hard to hack on it. I used this during the recent work to teach D/F conflicts to merge-recursive. Signed-off-by: Junio C Hamano <junkio@cox.net>