kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Denton Liu	245b9ba0ba	t3030: use test_path_is_missing() We use `test_must_fail test -d` to ensure that the directory is removed. However, test_must_fail() should only be used for git commands. Use test_path_is_missing() instead to check that the directory has been removed. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jonathan Tan	83e3ad3b12	merge-recursive: symlink's descendants not in way When the working tree has: - bar (directory) - bar/file (file) - foo (symlink to .) (note that lstat() for "foo/bar" would tell us that it is a directory) and the user merges a commit that deletes the foo symlink and instead contains: - bar (directory, as above) - bar/file (file, as above) - foo (directory) - foo/bar (file) the merge should happen without requiring user intervention. However, this does not happen. This is because dir_in_way(), when checking the working tree, thinks that "foo/bar" is a directory. But a symlink should be treated much the same as a file: since dir_in_way() is only checking to see if there is a directory in the way, we don't want symlinks in leading paths to sometimes cause dir_in_way() to return true. Teach dir_in_way() to also check for symlinks in leading paths before reporting whether a directory is in the way. Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Elijah Newren	9822175d2b	Ensure index matches head before invoking merge machinery, round N This is the bug that just won't die; there always seems to be another form of it somewhere. See the commit message of `55f39cf755` ("merge: fix misleading pre-merge check documentation", 2018-06-30) for a more detailed explanation), but in short: <quick summary> builtin/merge.c contains this important requirement for merge strategies: ...the index must be in sync with the head commit. The strategies are responsible to ensure this. This condition is important to enforce because there are two likely failure cases when the index isn't in sync with the head commit: * we silently throw away changes the user had staged before the merge * we accidentally (and silently) include changes in the merge that were not part of either of the branches/trees being merged Discarding users' work and mis-merging are both bad outcomes, especially when done silently, so naturally this rule was stated sternly -- but, unfortunately totally ignored in practice unless and until actual bugs were found. But, fear not: the bugs from this were fixed in commit `ee6566e8d7` ("[PATCH] Rewrite read-tree", 2005-09-05) through a rewrite of read-tree (again, commit `55f39cf755` has a more detailed explanation of how this affected merge). And it was fixed again in commit `160252f816` ("git-merge-ours: make sure our index matches HEAD", 2005-11-03) ...and it was fixed again in commit `3ec62ad9ff` ("merge-octopus: abort if index does not match HEAD", 2016-04-09) ...and again in commit `65170c07d4` ("merge-recursive: avoid incorporating uncommitted changes in a merge", 2017-12-21) ...and again in commit `eddd1a411d` ("merge-recursive: enforce rule that index matches head before merging", 2018-06-30) ...with multiple testcases added to the testsuite that could be enumerated in even more commits. Then, finally, in a patch in the same series as the last fix above, the documentation about this requirement was fixed in commit `55f39cf755` ("merge: fix misleading pre-merge check documentation", 2018-06-30), and we all lived happily ever after... </quick summary> Unfortunately, "ever after" apparently denotes a limited time and it expired today. The merge-recursive rule to enforce that index matches head was at the beginning of merge_trees() and would only trigger when opt->call_depth was 0. Since merge_recursive() doesn't call merge_trees() until after returning from recursing, this meant that the check wasn't triggered by merge_recursive() until it had first finished all the intermediate merges to create virtual merge bases. That is a potentially HUGE amount of computation (and writing of intermediate merge results into the .git/objects directory) before it errors out and says, in effect, "Sorry, I can't do any merging because you have some local changes that would be overwritten." Trying to enforce that all of merge_trees(), merge_recursive(), and merge_recursive_generic() checked the index == head condition earlier resulted in a bunch of broken tests. It turns out that merge_recursive() has code to drop and reload the cache while recursing to create intermediate virtual merge bases, but unfortunately that code runs even when no recursion is necessary. This unconditional dropping and reloading of the cache masked a few bugs: * builtin/merge-recursive.c: didn't even bother loading the index. * builtin/stash.c: feels like a fake 'builtin' because it repeatedly invokes git subprocesses all over the place, mixed with other operations. In particular, invoking "git reset" will reset the index on disk, but the parent process that invoked it won't automatically have its in-memory index updated. * t3030-merge-recursive.h: this test has always been broken in that it didn't make sure to make index match head before running. But, it didn't care about the index or even the merge result, just the verbose output while running. While commit `eddd1a411d` ("merge-recursive: enforce rule that index matches head before merging", 2018-06-30) should have uncovered this broken test, it used a test_must_fail wrapper around the merge-recursive call because it was known that the merge resulted in a rename/rename conflict. Thus, that fix only made this test fail for a different reason, and since the index == head check didn't happen until after coming all the way back out of the recursion, the testcase had enough information to pass the one check that it did perform. So, load the index in builtin/merge-recursive.c, reload the in-memory index in builtin/stash.c, and modify the t3030 testcase to correctly setup the index and make sure that the test fails in the expected way (meaning it reports a rename/rename conflict). This makes sure that all callers actually make the index match head. The next commit will then enforce the condition that index matches head earlier so this problem doesn't return in the future. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Eric Sunshine	b6c32f63f3	t3030: fix broken &&-chains Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
SZEDER Gábor	40dc533f57	t3030-merge-recursive: don't check the stderr of a subshell The two test checking 'git mmerge-recursive' in an empty worktree in 't3030-merge-recursive.sh' fail when the test script is run with '-x' tracing (and using a shell other than a Bash version supporting BASH_XTRACEFD). The reason for those failures is that the tests check the emptiness of a subshell's stderr, which includes the trace of commands executed in that subshell as well, throwing off the emptiness check. Note that both subshells execute four git commands each, meaning that checking the emptiness of the whole subshell implicitly ensures that not only 'git merge-recursive' but none of the other three commands outputs anything to their stderr. Note also that if one of those commands were to output anything on its stderr, then the current combined check would not tell us which one of those four commands the unexpected output came from. Save the stderr of those four commands only instead of the whole subshell, so it remains free from tracing output, and save and check them individually, so they will show us from which command the unexpected output came from. After this change t3030 passes with '-x', even when running with /bin/sh. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Junio C Hamano	f309e8e768	merge-recursive: do not look at the index during recursive merge When merging another branch into ours, if their tree is the same as the common ancestor's, we can declare that our tree represents the result of three-way merge. In such a case, the recursive merge backend incorrectly used to create a commit out of our index, even when the index has changes. A recent fix attempted to prevent this by adding a comparison between "our" tree and the index, but forgot that this check must be restricted only to the outermost merge. Inner merges performed by the recursive backend across merge bases are by definition made from scratch without having any local changes added to the index. The call to index_has_changes() during an inner merge is working on the index that has no relation to the merge being performed, preventing legitimate merges from getting carried out. Fix it by limiting the check to the outermost merge. Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
David Turner	5423d2e700	submodules: allow empty working-tree dirs in merge/cherry-pick When a submodule is being merged or cherry-picked into a working tree that already contains a corresponding empty directory, do not record a conflict. One situation where this bug appears is: - Commit 1 adds a submodule - Commit 2 removes that submodule and re-adds it into a subdirectory (sub1 to sub1/sub1). - Commit 3 adds an unrelated file. Now the user checks out commit 1 (first deinitializing the submodule), and attempts to cherry-pick commit 3. Previously, this would fail, because the incoming submodule sub1/sub1 would falsely conflict with the empty sub1 directory. This patch ignores the empty sub1 directory, fixing the bug. We only ignore the empty directory if the object being emplaced is a submodule, which expects an empty directory. Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
René Scharfe	a25716535b	merge-recursive: fix verbose output for multiple base trees 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>	9 years ago
Elia Pinto	85aea1e7e0	t/t3030-merge-recursive.sh: use the $( ... ) construct for command substitution 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>	9 years ago
Jeff King	6f50833e98	t6031: move triple-rename test to t3030 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>	10 years ago
Brad King	6e2068ae48	merge-recursive.c: tolerate missing files while refreshing index 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>	11 years ago
Brad King	29d9af586b	t3030-merge-recursive: test known breakage with empty work tree 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>	11 years ago
Johannes Sixt	bba56042e7	t3030: use test_ln_s_add to remove SYMLINKS prerequisite 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>	12 years ago
Ramkumar Ramachandra	67b6afe1ed	t3030 (merge-recursive): use test_expect_code 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>	14 years ago
Jeff King	814f7d902b	t3030: fix accidental success in symlink rename 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>	14 years ago
Junio C Hamano	f2c8c8007c	i18n: use test_i18ngrep in t2020, t2204, t3030, and t3200 Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Ævar Arnfjörð Bjarmason	2ce216eeda	i18n: git-merge "You have not concluded your merge" messages 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>	14 years ago
Jonathan Nieder	a48fcd8369	tests: add missing && 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>	15 years ago
Schalk, Ken	8a1c0d322e	t3030: Add a testcase for resolvable rename/add conflict with symlinks `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>	15 years ago
Schalk, Ken	d5af51053c	RE: [PATCH] Avoid rename/add conflict when contents are identical >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>	15 years ago
Matthieu Moy	e6c111b4c0	unpack_trees: group error messages by type 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>	15 years ago
Johannes Sixt	7d82b06d2b	merge-recursive: demonstrate an incorrect conflict with submodule 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>	15 years ago
Matthieu Moy	d38a30df7d	Be more user-friendly when refusing to do something because of conflict. 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>	15 years ago
Clemens Buchacher	c8c562a238	refuse to merge during a merge 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>	16 years ago
Alex Riesen	41f13af558	Remove empty directories in recursive merge 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>	17 years ago
Nanako Shiraishi	0cb0e143ff	tests: use "git xyzzy" form (t0000 - t3599) Converts tests between t0050-t3903. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	446247db78	merge: fix numerus bugs around "trivial merge" area 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>	17 years ago
Junio C Hamano	3af828634f	tests: do not use implicit "git diff --no-index" 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>	17 years ago
Junio C Hamano	a6080a0a44	War on whitespace 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>	18 years ago
Brian Gernhardt	744747ef1d	Remove case-sensitive file in t3030-merge-recursive. Rename "A" to the unused "c" Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	885b981075	t3030: merge-recursive backend test. 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>	18 years ago

34 Commits (1ac83f42da6437d74098f162fcfa37474c94e223)