Commit graph

20 commits

Author SHA1 Message Date
Johannes Sixt
fdf4f6c79b t6026: clarify the point of "kill $(cat sleep.pid)"
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-11 12:53:21 -08:00
Johannes Schindelin
a7d6bcc329 t6026: ensure that long-running script really is
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-10 15:57:06 -08:00
Junio C Hamano
b36b716cf6 Revert "t6026-merge-attr: don't fail if sleep exits early"
This reverts commit 734fde2d71.

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-10 15:55:13 -08:00
Junio C Hamano
3b03097d66 Revert "t6026-merge-attr: ensure that the merge driver was called"
This reverts commit c1e0dc59bd.

We are not interested in the stray process in the merge driver
started; we want it to be still around.
2016-11-10 15:54:12 -08:00
Andreas Schwab
c1e0dc59bd t6026-merge-attr: ensure that the merge driver was called
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-10 11:20:56 -08:00
Andreas Schwab
734fde2d71 t6026-merge-attr: don't fail if sleep exits early
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-11-08 15:29:24 -05:00
Johannes Sixt
5babb5bdb3 t6026-merge-attr: clean up background process at end of test case
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-09-07 11:40:22 -07:00
Ben Wijen
05d1ed6148 mingw: ensure temporary file handles are not inherited by child processes
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-23 09:09:55 -07:00
Ben Wijen
ad65f7e3b7 t6026-merge-attr: child processes must not inherit index.lock handles
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-08-18 13:56:45 -07:00
Junio C Hamano
e379fdf34f merge: refuse to create too cool a merge by default
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>
2016-03-23 12:04:48 -07:00
Junio C Hamano
49ac7358da Merge branch 'jc/ll-merge-expose-path'
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-24 12:21:45 -07:00
Junio C Hamano
ef45bb1f81 ll-merge: pass the original path to external drivers
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-06-04 15:36:32 -07:00
Jeff King
e6821d09e4 t: fix some trivial cases of ignored exit codes in loops
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>
2015-03-25 10:25:27 -07:00
Junio C Hamano
4c734803cb conflict-marker-size: add test and docs
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20 23:49:27 -08:00
Shawn O. Pearce
ed520a8f27 Merge branch 'mv/merge-recursive'
* 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-25 09:49:19 -07:00
Miklos Vajna
4271666046 builtin-merge: release the lockfile in try_merge_strategy()
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-06 19:49:51 -07:00
Nanako Shiraishi
3604e7c5c6 tests: use "git xyzzy" form (t3600 - t6999)
Converts tests between t3600-t6300.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03 14:13:59 -07:00
Junio C Hamano
153920da5b Custom low-level merge driver: change the configuration scheme.
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-18 12:30:26 -07:00
Junio C Hamano
f3ef6b6bbe Custom low-level merge driver support.
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-18 01:43:42 -07:00
Junio C Hamano
47579efc00 Add a demonstration/test of customized merge.
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>
2007-04-17 14:21:22 -07:00