summaryrefslogtreecommitdiff
path: root/t/t6026-merge-attr.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-11-11t6026: clarify the point of "kill $(cat sleep.pid)"Libravatar Johannes Sixt1-1/+9
We lengthened the time the leftover process sleeps in the previous commit to make sure it will be there while 'git merge' runs and finishes. It therefore needs to be killed before leaving the test. And it needs to be killed even when 'git merge' fails, so it has to be triggered via test_when_finished mechanism. Explain all that in a large comment, and move the use site of test_when_finished to immediately before 'git merge' invocation, where the process is spawned. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-10t6026: ensure that long-running script really isLibravatar Johannes Schindelin1-4/+4
When making sure that background tasks are cleaned up in 5babb5b (t6026-merge-attr: clean up background process at end of test case, 2016-09-07), we considered to let the background task sleep longer, just to be certain that it will still be running when we want to kill it after the test. Sadly, the assumption appears not to hold true that the test case passes quickly enough to kill the background task within a second. Simply increase it to an hour. No system can be possibly slow enough to make above-mentioned assumption incorrect. Reported by Andreas Schwab. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-10Revert "t6026-merge-attr: don't fail if sleep exits early"Libravatar Junio C Hamano1-1/+1
This reverts commit 734fde2d7167e4b20d2ff6062ade3846949b0741. The point of the test is that the stray process was still running when 'git merge' did its thing through its completion, so a failure to "kill" it means we didn't give a condition to the test to trigger a possible future breakage. Appending "|| :" to the "kill" is sweeping a test-bug under the rug.
2016-11-10Revert "t6026-merge-attr: ensure that the merge driver was called"Libravatar Junio C Hamano1-2/+1
This reverts commit c1e0dc59bddce765761a6f863c66ee0cd4b2ca09. We are not interested in the stray process in the merge driver started; we want it to be still around.
2016-11-10t6026-merge-attr: ensure that the merge driver was calledLibravatar Andreas Schwab1-1/+2
Explicitly check for the existence of the pid file to test that the merge driver was actually called. Signed-off-by: Andreas Schwab <schwab@suse.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-08t6026-merge-attr: don't fail if sleep exits earlyLibravatar Andreas Schwab1-1/+1
Commit 5babb5bdb3 ("t6026-merge-attr: clean up background process at end of test case") added a kill command to clean up after the test, but this can fail if the sleep command exits before the cleanup is executed. Ignore the error from the kill command. Signed-off-by: Andreas Schwab <schwab@suse.de> Signed-off-by: Jeff King <peff@peff.net>
2016-09-07t6026-merge-attr: clean up background process at end of test caseLibravatar Johannes Sixt1-0/+2
The process spawned in the hook uses the test's trash directory as CWD. As long as it is alive, the directory cannot be removed on Windows. Although the test succeeds, the 'test_done' that follows produces an error message and leaves the trash directory around. Kill the process before the test case advances. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-23mingw: ensure temporary file handles are not inherited by child processesLibravatar Ben Wijen1-1/+1
When the index is locked and child processes inherit the handle to said lock and the parent process wants to remove the lock before the child process exits, on Windows there is a problem: it won't work because files cannot be deleted if a process holds a handle on them. The symptom: Rename from 'xxx/.git/index.lock' to 'xxx/.git/index' failed. Should I try again? (y/n) Spawning child processes with bInheritHandles==FALSE would not work because no file handles would be inherited, not even the hStdXxx handles in STARTUPINFO (stdin/stdout/stderr). Opening every file with O_NOINHERIT does not work, either, as e.g. git-upload-pack expects inherited file handles. This leaves us with the only way out: creating temp files with the O_NOINHERIT flag. This flag is Windows-specific, however. For our purposes, it is equivalent to O_CLOEXEC (which does not exist on Windows), so let's just open temporary files with the O_CLOEXEC flag and map that flag to O_NOINHERIT on Windows. As Eric Wong pointed out, we need to be careful to handle the case where the Linux headers used to compile Git support O_CLOEXEC but the Linux kernel used to run Git does not: it returns an EINVAL. This fixes the test that we just introduced to demonstrate the problem. Signed-off-by: Ben Wijen <ben@wijen.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-18t6026-merge-attr: child processes must not inherit index.lock handlesLibravatar Ben Wijen1-0/+13
On Windows, a file cannot be removed unless all file handles to it have been released. Hence it is particularly important to close handles when spawning children (which would probably not even know that they hold on to those handles). The example chosen for this test is a custom merge driver that indeed has no idea that it blocks the deletion of index.lock. The full use case is a daemon that lives on after the merge, with subsequent invocations handing off to the daemon, thereby avoiding hefty start-up costs. We simulate this behavior by simply sleeping one second. Note that the test only fails on Windows, due to the file locking issue. Since we have no way to say "expect failure with MINGW, success otherwise", we simply skip this test on Windows for now. Signed-off-by: Ben Wijen <ben@wijen.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-23merge: refuse to create too cool a merge by defaultLibravatar Junio C Hamano1-1/+2
While it makes sense to allow merging unrelated histories of two projects that started independently into one, in the way "gitk" was merged to "git" itself aka "the coolest merge ever", such a merge is still an unusual event. Worse, if somebody creates an independent history by starting from a tarball of an established project and sends a pull request to the original project, "git merge" however happily creates such a merge without any sign of something unusual is happening. Teach "git merge" to refuse to create such a merge by default, unless the user passes a new "--allow-unrelated-histories" option to tell it that the user is aware that two unrelated projects are merged. Because such a "two project merge" is a rare event, a configuration option to always allow such a merge is not added. We could add the same option to "git pull" and have it passed through to underlying "git merge". I do not have a fundamental opposition against such a feature, but this commit does not do so and instead leaves it as low-hanging fruit for others, because such a "two project merge" would be done after fetching the other project into some location in the working tree of an existing project and making sure how well they fit together, it is sufficient to allow a local merge without such an option pass-through from "git pull" to "git merge". Many tests that are updated by this patch does the pass-through manually by turning: git pull something into its equivalent: git fetch something && git merge --allow-unrelated-histories FETCH_HEAD If somebody is inclined to add such an option, updated tests in this change need to be adjusted back to: git pull --allow-unrelated-histories something Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-24Merge branch 'jc/ll-merge-expose-path'Libravatar Junio C Hamano1-5/+9
Traditionally, external low-level 3-way merge drivers are expected to produce their results based solely on the contents of the three variants given in temporary files named by %O, %A and %B on their command line. Additionally allow them to look at the final path (given by %P). * jc/ll-merge-expose-path: ll-merge: pass the original path to external drivers
2015-06-04ll-merge: pass the original path to external driversLibravatar Junio C Hamano1-5/+9
The interface to custom low-level merge driver was modeled to be capable of driving programs like "merge" (from the RCS suite) that can produce result solely by looking at three files that hold contents of common ancestor, ours and theirs. The information we feed to the external drivers via the command line placeholders %O, %A, and %B were designed to be purely about contents by giving names of the temporary files that hold these variants without exposing the original pathname. No matter where the result goes, merging the same three variants should produce the same result, contents is the king, that is the Git way. The external driver interface, however, is meant to help people to step outside the Git worldview, and sometimes people want to know the final path that the resulting merged contents would be stored in. Expose this to the external drivers via a new placeholder %P. Requested-by: Andreas Gondek Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-25t: fix some trivial cases of ignored exit codes in loopsLibravatar Jeff King1-3/+3
These are all cases where we do a setup step of the form: for i in $foo; do set_up $i || break done && more_setup would not notice a failure in set_up (because break always returns a 0 exit code). These are just setup steps that we do not expect to fail, but it does not hurt to be defensive. Most can be fixed by converting the "break" to a "return 1" (since we eval our tests inside a function for just this purpose). A few of the loops are inside subshells, so we can use just "exit 1" to break out of the subshell. And a few can actually be made shorter by just unrolling the loop. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20conflict-marker-size: add test and docsLibravatar Junio C Hamano1-0/+12
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-25Merge branch 'mv/merge-recursive'Libravatar Shawn O. Pearce1-0/+22
* mv/merge-recursive: builtin-merge: release the lockfile in try_merge_strategy() merge-recursive: get rid of virtual_id merge-recursive: move current_{file,directory}_set to struct merge_options merge-recursive: move the global obuf to struct merge_options merge-recursive: get rid of the index_only global variable merge-recursive: move call_depth to struct merge_options cherry-pick/revert: make direct internal call to merge_tree() builtin-merge: avoid run_command_v_opt() for recursive and subtree merge-recursive: introduce merge_options merge-recursive.c: Add more generic merge_recursive_generic() Split out merge_recursive() to merge-recursive.c
2008-09-06builtin-merge: release the lockfile in try_merge_strategy()Libravatar Miklos Vajna1-0/+22
Once we committed the locked index, we should release the lockfile. In most cases this is done automatically when the process ends, but this is not true in this case. [jc: with additional tests from Eric Raible] Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03tests: use "git xyzzy" form (t3600 - t6999)Libravatar Nanako Shiraishi1-6/+6
Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-18Custom low-level merge driver: change the configuration scheme.Libravatar Junio C Hamano1-2/+6
This changes the configuration syntax for defining a low-level merge driver to be: [merge "<<drivername>>"] driver = "<<command line>>" name = "<<driver description>>" which is much nicer to read and is extensible. Credit goes to Martin Waitz and Linus. In addition, when we use an external low-level merge driver, it is reported as an extra output from merge-recursive, using the value of merge.<<drivername>.name variable. The demonstration in t6026 has also been updated. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-18Custom low-level merge driver support.Libravatar Junio C Hamano1-1/+70
This allows users to specify custom low-level merge driver per path, using the attributes mechanism. Just like you can specify one of built-in "text", "binary", "union" low-level merge drivers by saying: * merge=text .gitignore merge=union *.jpg merge=binary pick a name of your favorite merge driver, and assign it as the value of the 'merge' attribute. A custom low-level merge driver is defined via the config mechanism. This patch introduces 'merge.driver', a multi-valued configuration. Its value is the name (i.e. the one you use as the value of 'merge' attribute) followed by a command line specification. The command line can contain %O, %A, and %B to be interpolated with the names of temporary files that hold the common ancestor version, the version from your branch, and the version from the other branch, and the resulting command is spawned. The low-level merge driver is expected to update the temporary file for your branch (i.e. %A) with the result and exit with status 0 for a clean merge, and non-zero status for a conflicted merge. A new test in t6026 demonstrates a sample usage. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-17Add a demonstration/test of customized merge.Libravatar Junio C Hamano1-0/+72
This demonstrates how the new low-level per-path merge backends, union and ours, work, and shows how they are controlled by the gitattribute mechanism. Signed-off-by: Junio C Hamano <junkio@cox.net>