delta/git.git/apply.c, branch v1.0.4

xread/xwrite: do not worry about EINTR at calling sites.

2005-12-20T02:28:16+00:00

We had errno==EINTR check after read(2)/write(2) sprinkled all
over the places, always doing continue.  Consolidate them into
xread()/xwrite() wrapper routines.

Credits for suggestion goes to HPA -- bugs are mine.

Signed-off-by: Junio C Hamano

git-apply: work from subdirectory.

2005-11-29T07:13:01+00:00

When applying a patch to index file, we need to know where GIT_DIR is;
use setup_git_directory() to find it out.  This also allows us to work
from a subdirectory if we wanted to.

When git-apply is run from a subdirectory, it applies the given patch
only to the files under the current directory and below.

Signed-off-by: Junio C Hamano

Deal with binary diff output from GNU diff 2.8.7

2005-11-18T05:14:29+00:00

Some vintage of diff says just "Files X and Y differ\n", instead
of "Binary files X and Y differ\n", so catch both patterns.

Signed-off-by: Junio C Hamano

apply: allow-binary-replacement.

2005-11-17T00:20:40+00:00

A new option, --allow-binary-replacement, is introduced.

When you feed a diff that records full SHA1 name of pre- and
post-image blob on its index line to git-apply with this option,
the post-image blob replaces the path if what you have in the
working tree matches the pre-image _and_ post-image blob is
already available in the object directory.

Later we _might_ want to enhance the diff output to also include
the full binary data of the post-image, to make this more
useful, but this is good enough for local rebasing application.

Signed-off-by: Junio C Hamano

git-apply: fail if a patch cannot be applied.

2005-11-16T22:12:56+00:00

Recently we fixed 'git-apply --stat' not to barf on a binary
differences.  But it accidentally broke the error detection when
we actually attempt to apply them.

This commit fixes the problem and adds test cases.

Signed-off-by: Junio C Hamano

apply: fix binary patch detection.

2005-11-15T01:15:07+00:00

The comparison to find "Binary files " string was looking at a
wrong place when offset != 0.

Also, we may have the full 40-byte textual sha1 on the index
line; two off-by-one errors prevented it.

Signed-off-by: Junio C Hamano

Documentation: git-apply --no-add

2005-11-12T05:18:18+00:00

This is a specialized hack to help no-base merges, but other
people might find it useful, so let's document it.

Signed-off-by: Junio C Hamano

merge-one-file: use common as base, instead of emptiness.

2005-11-12T05:18:17+00:00

Unlike the previous round that merged the path added differently
in each branches using emptiness as the base, compute a common
version and use it as input to 'merge' program.

This would show the resulting (still conflicting) file left in
the working tree as:

	common file contents...
	<<<<<< FILENAME
	version from our branch...
	======
	version from their branch...
	>>>>>> .merge_file_XXXXXX
	more common file contents...

when both sides added similar contents.

Signed-off-by: Junio C Hamano

git-apply: do not fail on binary diff when not applying nor checking.

2005-11-09T23:19:50+00:00

We run git-apply with --stat and --summary at the end of the pull
by default, which causes it to barf when the pull brought in changes
to binary files.  Just mark them as binary patch and proceed when
not applying nor checking.

[jc: I almost missed --check until I saw Linus did something similar.]

Signed-off-by: Junio C Hamano

git-apply --numstat

2005-10-29T05:28:57+00:00

The new option, --numstat, shows number of inserted and deleted
lines for each path.  It is similar to --stat output but is
meant to be more machine friendly by giving number of added and
deleted lines and unabbreviated paths.

Signed-off-by: Junio C Hamano