git-apply running inside a subdirectory, with or without --index,
used to always assume that the patch is formatted in such a way
to apply with -p1 from the toplevel, but it is more useful and
consistent with the use of "GNU patch -p1" if it defaulted to
assume that its input is meant to apply at the level it is
invoked in.
This changes the behaviour. It used to be that the patch
generated this way would apply without any trick:
edit Documentation/Makefile
git diff >patch.file
cd Documentation
git apply ../patch.file
You need to give an explicit -p2 to git-apply now. On the other
hand, if you got a patch from somebody else who did not follow
"patch is to apply from the top with -p1" convention, the input
patch would start with:
diff -u Makefile.old Makefile
--- Makefile.old
+++ Makefile
and in such a case, you can apply it with:
git apply -p0 patch.file
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a patch modifies (not deletes) the last file in a
directory, because we treat a modification just as deletion
followed by creation, and deleting the last file in a directory
automatically rmdir(2)'s that directory, we ended up removing
the directory, which can potentially be the cwd, and then
recreating the same directory to create the patch result.
Avoid the rmdir step when remove_file() is called only because
we are replacing it with the result by later calling
create_file().
Signed-off-by: Junio C Hamano <junkio@cox.net>
This teaches git-apply that the data read from and written to
the filesystem might need to get converted to adjust for local
line-ending convention.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When neither --index nor --cached was used, git-apply did not
try calling setup_git_directory(), which means it did not look
at configuration files at all. This fixes it to call the setup
function but still allow the command to be run in a directory
not controlled by git.
The bug probably meant that 'git apply', not moving up to the
toplevel, did not apply properly formatted diffs from the
toplevel when you are inside a subdirectory, even though 'git
apply --index' would. As a side effect, this patch fixes it as
well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we do not trust executable bit from lstat(2), we copied
existing ce_mode bits without checking if the filesystem object
is a regular file (which is the only thing we apply the "trust
executable bit" business) nor if the blob in the index is a
regular file (otherwise, we should do the same as registering a
new regular file, which is to default non-executable).
Noticed by Johannes Sixt.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The static variable "prefix" was shadowed by an unused parameter
of the same name. In case of execution in a subdirectory, the
static variable was accessed, leading to a crash.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Returning negative value from there does not stop the caller from using
the earlier part.
Noticed by Linus.
Signed-off-by: Junio C Hamano <junkio@cox.net>
find_header() function is used to read and parse the patchfile
and it detects errors in the patch, but one place ignored the
error and went ahead, which was quite bad.
Noticed by Jeff Garzik.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a mechanical clean-up of the way *.c files include
system header files.
(1) sources under compat/, platform sha-1 implementations, and
xdelta code are exempt from the following rules;
(2) the first #include must be "git-compat-util.h" or one of
our own header file that includes it first (e.g. config.h,
builtin.h, pkt-line.h);
(3) system headers that are included in "git-compat-util.h"
need not be included in individual C source files.
(4) "git-compat-util.h" does not have to include subsystem
specific header files (e.g. expat.h).
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
* maint:
Remove unsupported C99 style struct initializers in git-archive.
Remove SIMPLE_PROGRAMS and make git-daemon a normal program.
Use ULONG_MAX rather than implicit cast of -1.
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>
* jc/cache-tree: (26 commits)
builtin-rm: squelch compiler warnings.
git-write-tree writes garbage on sparc64
Fix crash when reading the empty tree
fsck-objects: do not segfault on missing tree in cache-tree
cache-tree: a bit more debugging support.
read-tree: invalidate cache-tree entry when a new index entry is added.
Fix test-dump-cache-tree in one-tree disappeared case.
fsck-objects: mark objects reachable from cache-tree
cache-tree: replace a sscanf() by two strtol() calls
cache-tree.c: typefix
test-dump-cache-tree: validate the cached data as well.
cache_tree_update: give an option to update cache-tree only.
read-tree: teach 1-way merege and plain read to prime cache-tree.
read-tree: teach 1 and 2 way merges about cache-tree.
update-index: when --unresolve, smudge the relevant cache-tree entries.
test-dump-cache-tree: report number of subtrees.
cache-tree: sort the subtree entries.
Teach fsck-objects about cache-tree.
index: make the index file format extensible.
cache-tree: protect against "git prune".
...
Conflicts:
Makefile, builtin.h, git.c: resolved the same way as in next.
* master: (40 commits)
Clean up sha1 file writing
Builtin git-cat-file
builtin format-patch: squelch content-type for 7-bit ASCII
CMIT_FMT_EMAIL: Q-encode Subject: and display-name part of From: fields.
add more informative error messages to git-mktag
remove the artificial restriction tagsize < 8kb
git-rebase: use canonical A..B syntax to format-patch
git-format-patch: now built-in.
fmt-patch: Support --attach
fmt-patch: understand old <his> notation
Teach fmt-patch about --keep-subject
Teach fmt-patch about --numbered
fmt-patch: implement -o <dir>
fmt-patch: output file names to stdout
Teach fmt-patch to write individual files.
Use RFC2822 dates from "git fmt-patch".
git-fmt-patch: thinkofix to show [PATCH] properly.
rename internal format-patch wip
Minor tweak on subject line in --pretty=email
Tentative built-in format-patch.
...
