This patch fixes a sparse warning about inaccurate_eof being a
"dubious one-bit signed bitfield", makes three more binary
variables members of this (now unsigned) bitfield and adds a
short comment to indicate the nature of two ternary variables.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We do not even know number of lines so showing it as 0 0 is
lying. This would also help Porcelains like cvsexportcommit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
At least one (older) version of the Solaris C compiler won't allow
'unsigned long x = -1' without explicitly casting -1 to a type of
unsigned long. So instead use ULONG_MAX, which is really the
correct constant anyway.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We deduced a GNU diff output that does not use /dev/null convention
as creation (deletion) diff correctly by looking at the lack of context
and deleted lines (added lines), but forgot to reset the new (old) name
field properly.
This was a regression when we added a workaround for --unified=0 insanity.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The latest GNU diff from CVS emits an empty line to express
an empty context line, instead of more traditional "single
white space followed by a newline". Do not get broken by it.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Most callers of write_sha1_file_prepare() are only interested in the
resulting hash but don't care about the returned file name or the header.
This patch adds a simple wrapper named hash_sha1_file() which does just
that, and converts potential callers.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Somebody was wondering on #git channel why a git generated diff
does not apply with GNU patch when the filename contains a SP.
It is because GNU patch expects to find TAB (and trailing timestamp)
on ---/+++ (old_name and new_name) lines after the filenames.
The "diff --git" output format was carefully designed to be
compatible with GNU patch where it can, but whitespace
characters were always a pain.
We can make our output a bit more GNU patch friendly by adding an
extra TAB (but not trailing timestamp) to old/new name lines when
the filename as a SP in it. This updates git-apply to prepare
ourselves to accept such a patch, but we still do not generate
output that is patch friendly yet. That change needs to wait
until everybody has this change.
When a filename contains a real tab, "diff --git" format
always c-quotes it as discussed on the list with GNU patch
maintainer previously:
http://marc.theaimsgroup.com/?l=git&m=112927316408690&w=2
so there should be no downside.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes --whitespace={warn,error,strip} option to also notice
the leading whitespace errors in addition to the trailing
whitespace errors. Spaces that are followed by a tab in indent
are detected as errors, and --whitespace=strip option fixes them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Historically we did not allow binary patch applied without an
explicit permission from the user, and this flag was the way to
do so. This makes the flag a no-op by always allowing binary
patch application.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Like xmalloc and xrealloc xstrdup dies with a useful message if
the native strdup() implementation returns NULL rather than a
valid pointer.
I just tried to use xstrdup in new code and found it to be missing.
However I expected it to be present as xmalloc and xrealloc are
already commonly used throughout the code.
[jc: removed the part that deals with last_XXX, which I am
finding more and more dubious these days.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
After a failed "git am" attempt:
git apply --reject --verbose .dotest/patch
applies hunks that are applicable and leaves *.rej files the
rejected hunks, and it reports what it is doing. With --index,
files with a rejected hunk do not get their index entries
updated at all, so "git diff" will show the hunks that
successfully got applied.
Without --verbose to remind the user that the patch updated some
other paths cleanly, it is very easy to lose track of the status
of the working tree, so --reject implies --verbose.
Signed-off-by: Junio C Hamano <junkio@cox.net>
builtin-apply.c defines a local variable 'c' which is used only
once and then later gets shadowed by another instance of 'c'.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
builtin-apply.c and builtin-push.c uses a local variable called 'error'
which shadows the error() function.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With the new flag "--reject", hunks that do not apply are sent to
the standard output, and the usable hunks are applied. The command
itself exits with non-zero status when this happens, so that the
user or wrapper can take notice and sort the remaining mess out.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Parsing of a binary hunk did not consume the terminating blank
line. When applying in reverse, it did not use the second,
reverse binary hunk.
Signed-off-by: Junio C Hamano <junkio@cox.net>
[jc: I needed to hand merge the changes to the updated codebase,
so the result needs to be checked.]
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Replace sha1 comparisons to null_sha1 with a global inline (which previously an
unused static inline in builtin-apply.c)
[jc: with a fix from Jonas Fonseca.]
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This cleans up the implementation of "git-apply --binary", and
implements reverse application of binary patches (when git-diff
is converted to emit reversible binary patches).
Earlier, the types of encoding (either deflated literal or
deflated delta) were stored in is_binary field in struct patch,
which meant that we cannot store more than one fragment that
differ in the encoding for a patch. This moves the information
to a field in struct fragment that is otherwise unused for
binary patches, and makes it possible to hang two (or more, but
two is enough) hunks for a binary patch.
The original "binary patch" output from git-diff is internally
parsed into an "is_binary" patch with one fragment. Upcoming
reversible binary patch output will have two fragments, the
first one being the forward patch and the second one the reverse
patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Having is_reverse in each patch did not make sense. This will hopefully
simplify the work needed to introduce reversible binary diff format.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Most of the callers except the one in refs.c use the function to
update the index file. Among the index writers, everybody
except write-tree dies if they cannot open it for writing.
This gives the function an extra argument, to tell it to die
when it cannot create a new file as the lockfile.
The only caller that does not have to die is write-tree, because
updating the index for the cache-tree part is optional and not
being able to do so does not affect the correctness. I think we
do not have to be so careful and make the failure into die() the
same way as other callers, but that would be a different patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The internal representation of the result is counted string
(i.e. char *buf and ulong size), which is fine for writing out
to regular file, but throwing the buf at symlink(2) was a
no-no.
Reported by Willy Tarreau.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the calling convention of built-in commands and
passes the "prefix" (i.e. pathname of $PWD relative to the
project root level) down to them.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
On cygwin, when you try to create a symlink over a directory, you do
not get EEXIST, but EACCES.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A type-change diff is always split into a patch to delete old,
immediately followed by a patch to create new. check_patch()
routine noticed that the path to be created already exists in
the working tree and/or in the index when looking at the
creation patch and mistakenly thought it to be an error.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reworks write_out_result() loop so we first remove the paths that
are to go away and then create them after finishing all the removal.
This is necessary when a patch creates a file "foo" and removes a file
"foo/bar".
Signed-off-by: Junio C Hamano <junkio@cox.net>
When creating a new file where a directory used to be (or the user had
an empty directory) the code did not check the result from lstat() closely
enough, and mistakenly thought the path already existed in the working tree.
This does not fix the problem where you have a patch that creates a file
at "foo" and removes a file at "foo/bar" (which presumably is the last file
in "foo/" directory in the original). For that, we would need to restructure
write_out_results() loop.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This doesn't make the code uglier or harder to read, yet it makes the
code more portable. This also simplifies checking for other potential
incompatibilities. "gcc -std=c89 -pedantic" can flag many incompatible
constructs as warnings, but C99 comments will cause it to emit an error.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The only visible change is that git-blame doesn't understand
"--compability" anymore, but it does accept "--compatibility" instead,
which is already documented.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It does not make much sense to build git whose behaviour is
different depending on the brokenness of diff implementation of
the platform because the brokenness of the patch that is applied
with the tool depends on brokenness of the diff the person who
generates the patch uses. So we do not use NO_ACCURATE_DIFF
anymore, but help people to apply patches that do not record
incomplete lines correctly with a runtime flag.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
ANSI C99 doesn't allow void-pointer arithmetic. This patch fixes this in
various ways. Usually the strategy that required the least changes was used.
Signed-off-by: Florian Forster <octo@verplant.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The framework to create lockfiles that are removed at exit is
first used to reliably write the index file, but it is
applicable to other things, so stop calling it "cache_file".
This also rewords a few remaining error message that called the
index file "cache file".
Signed-off-by: Junio C Hamano <junkio@cox.net>
The --cached mode does not deal with the working tree, so we
should not check it with lstat. An earlier code omitted the
call to lstat but forgot to omit the check for the errno.
Signed-off-by: Junio C Hamano <junkio@cox.net>
A new flag "--cached" takes the cached data, applies the patch
and stores the result in the index, without using the working
tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When multiple patches are passed to git-apply, it will attempt
to open multiple file descriptors to an index, which means
multiple entries will be in the circular cache_file_list.
This change makes git-apply only open the index once and
write the index at exit.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the user interface and generated diff data format.
* "diff --binary" is used to signal that we want an e-mailable
binary patch. It implies --full-index and -p.
* "apply --allow-binary-replacement" acquired a short synonym
"apply --binary".
* After the "GIT binary patch\n" header line there is a token
to record which binary patch mechanism was used, so that we
can extend it later. Currently there are two mechanisms
defined: "literal" and "delta". The former records the
deflated postimage and the latter records the deflated delta
from the preimage to postimage.
For purely implementation convenience, I added the deflated
length after these "literal/delta" tokens (otherwise the
decoding side needs to guess and reallocate the buffer while
inflating). Improvement patches are very welcomed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rene Scharfe