| Age | Commit message (Collapse) | Author |
|---|
|
This changes the default --whitespace policy to nowarn when we
are only getting --stat, --summary etc. IOW when not applying
the patch. When applying the patch, the default is warn (spit
out warning message but apply the patch).
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Andrew insists --whitespace=warn should be the default, and I
tend to agree. This introduces --whitespace=warn, so if your
project policy is more lenient, you can squelch them by having
apply.whitespace=nowarn in your configuration file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
The new configuration option apply.whitespace can take one of
"warn", "error", "error-all", or "strip". When git-apply is run
to apply the patch to the index, they are used as the default
value if there is no command line --whitespace option.
Andrew can now tell people who feed him git trees to update to
this version and say:
git repo-config apply.whitespace error
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
This by default makes --whitespace=warn, error, and strip to
warn only the first 5 additions of trailing whitespaces. A new
option --whitespace=error-all can be used to view all of them
before applying.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
In addition to fixing obvious command line parsing bugs in the
previous round, this changes the following:
* Adds "--whitespace=strip". This applies after stripping the
new trailing whitespaces introduced to the patch.
* The output error message format is changed to say
"patch-filename:linenumber:contents of the line". This makes
it similar to typical compiler error message format, and
helps C-x ` (next-error) in Emacs compilation buffer.
* --whitespace=error and --whitespace=warn do not stop at the
first error. We might want to limit the output to say first
20 such lines to prevent cluttering, but on the other hand if
you are willing to hand-fix after inspecting them, getting
everything with a single run might be easier to work with.
After all, somebody has to do the clean-up work somewhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
On Sat, 25 Feb 2006, Andrew Morton wrote:
>
> I'd suggest a) git will simply refuse to apply such a patch unless given a
> special `forcing' flag, b) even when thus forced, it will still warn and c)
> with a different flag, it will strip-then-apply, without generating a
> warning.
This doesn't do the "strip-then-apply" thing, but it allows you to make
git-apply generate a warning or error on extraneous whitespace.
Use --whitespace=warn to warn, and (surprise, surprise) --whitespace=error
to make it a fatal error to have whitespace at the end.
Totally untested, of course. But it compiles, so it must be fine.
HOWEVER! Note that this literally will check every single patch-line with
"+" at the beginning. Which means that if you fix a simple typo, and the
line had a space at the end before, and you didn't remove it, that's still
considered a "new line with whitespace at the end", even though obviously
the line wasn't really new.
I assume this is what you wanted, and there isn't really any sane
alternatives (you could make the warning activate only for _pure_
additions with no deletions at all in that hunk, but that sounds a bit
insane).
Linus
|
|
As far as I can see, create_subdirectories() in apply.c just
duplicates the functionality of safe_create_leading_directories() from
sha1_file.c. The former has a warm, fuzzy const parameter, but that's
not important.
The potential problem with EEXIST and creating directories should
never occur here, but will be removed by future
safe_create_leading_directories() changes. Other uses of EEXIST in
apply.c should be fine barring intentionally malicious behavior.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
This only applies to traditional diffs, not to git diffs.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
It can happen if the temporary file already exists (i.e. after a panic
and reboot).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
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 <junkio@cox.net>
|
|
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 <junkio@cox.net>
|
|
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 <junkio@cox.net>
|
|
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 <junkio@cox.net>
|
|
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 <junkio@cox.net>
|
|
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 <junkio@cox.net>
|
|
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 <junkio@cox.net>
|
|
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 <junkio@cox.net>
|
|
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 <junkio@cox.net>
|
|
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 <junkio@cox.net>
|
|
Linus says he does not use it (and the thinking behind its initial
introduction), and neither Cogito nor StGIT uses it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Do our own ctype.h, just to get the sane semantics: we want
locale-independence, _and_ we want the right signed behaviour. Plus we
only use a very small subset of ctype.h anyway (isspace, isalpha,
isdigit and isalnum).
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Add an new option --show-index-info to git-apply command to
summarize the index information new git-diff outputs. The
command shows something similar to git-ls-files --stage output
for the pre-change image:
100644 7be5041... apply.c
100644 ec2a161... cache.h
...
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
The original plan was to do 3-way merge between local working tree,
index and the patch being applied, but that was never implemented.
Retire the flag to control its behaviour.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
This patch teaches 'git-apply --index' to automatically check
out a file being patched. This happens only when the working
tree does not have it checked out.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
A patch that contains no actual diff, and that doesn't change any
meta-data is bad. It shouldn't be a patch at all, and git-apply shouldn't
just accept it.
This caused a corrupted patch to be silently applied as an empty change in
the kernel, because the corruption ended up making the patch look empty.
An example of such a patch is one that contains the patch header, but
where the initial fragment header (the "@@ -nr,.." line) is missing,
causing us to not parse any fragments.
The real "patch" program will also flag such patches as bad, with the
message
patch: **** Only garbage was found in the patch input.
and we should do likewise.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
The message "\ No newline at end of file" used by diff(1) to mark
an incomplete line is locale dependent. We can't assume more than
that it begins with "\ ".
For example, given two files, "foo" and "bar", with appropriate
contents, 'diff -u foo bar' will produce the following output on
my system:
--- foo 2005-09-04 18:59:38.000000000 +0200
+++ bar 2005-09-04 18:59:16.000000000 +0200
@@ -1 +1 @@
-foobar
+foo
\ Ingen nyrad vid filslut
[jc: the check for the marker still uses the line length being no less
than 12 bytes for a sanity check, but I think it is safe to assume
that in other locales. I haven't checked the .po files from diff, tho'.]
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
|
|
Stop processing and return NULL if we encounter a '\n' character
before we have two matching names in the git header.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Omitting the first branch in ?: is a GNU extension. Cute,
but not supported by other compilers. Replaced mostly
by explicit tests. Calls to getenv() simply are repeated
on non-GNU compilers.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
|
|
Without this patch, git-apply does not retain the mode when renaming or
copying files.
[jc: Good catch, Johannes. I added a test case to demonstrate the
breackage in the original.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
GCC's format __attribute__ is good for checking errors, especially
with -Wformat=2 parameter. This fixes most of the reported problems
against 2005-08-09 snapshot.
|
|
When git-apply was printing out long filenames, it used to just truncate
them to show the last "max_len" characters of the filename. Which can be
really quite ugly (note the two filenames that have just been silently
truncated from the beginning - it looks even worse when there are lots
of them, like there were in the current v2.6.13-rc4 cris arch update):
Documentation/video4linux/README.saa7134 | 9
Documentation/video4linux/bttv/Cards | 74
umentation/video4linux/hauppauge-wintv-cx88-ir.txt | 54
Documentation/video4linux/lifeview.txt | 42
mentation/video4linux/not-in-cx2388x-datasheet.txt | 41
Documentation/w1/w1.generic | 107
With this patch it now looks like so:
Documentation/video4linux/README.saa7134 | 9
Documentation/video4linux/bttv/Cards | 74
.../video4linux/hauppauge-wintv-cx88-ir.txt | 54
Documentation/video4linux/lifeview.txt | 42
.../video4linux/not-in-cx2388x-datasheet.txt | 41
Documentation/w1/w1.generic | 107
ie we've made it clear with an ellipsis that we've cut off something from
the beginning, and it also tries to do it cleanly at a subdirectory level.
Signed-off-by: Linus "good taste" Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Adds --exclude=pattern option to the "git-apply" command. This
was useful while reimporting the BKCVS patchset dump of the
Linux kernel, starting at 2.4.0 and ending at 2.6.12-rc2 Ingo
announced some time ago to exclude BitKeeper directory.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The parsing code had a bug that failed to recognize an
incomplete line at the end of a fragment, and the fragment
application code had a comparison bug to recognize such. Fix
them to handle incomplete lines correctly.
Add a test script for patches with various combinations of
complete and incomplete lines to make sure the fix works.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The more recent --apply option was not described.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
We write them under another name and rename them to their destination,
so that if something bad happens in the middle, we won't have caused any
bigger harm.
Also, this makes the writing be NFS "intr" safe, and as a side effects
makes sure that if the target is hardlinked (or symlinked) we will have
broken the link.
|
|
apply.c: In function `show_rename_copy':
apply.c:1147: warning: field precision is not type int (arg 3)
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
IIRC our strategy was to let the users' umask take care of the
final mode bits. This patch fixes places that deviate from it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Mainly making a lot of local functions and variables be marked "static",
but there was a "zero as NULL" warning in there too.
|
|
diffstat
Also, remove debugging statement about applying a fragment at an offset.
|
|
Typical expected usage is "git-apply --stat --summary" to show
diffstat plus dense description of information available in git
extended headers, such as creations, renames, and mode changes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
When a patch is a git extended rename/copy patch, "git-apply
--stat" showed the old filename. Change it to show the new
filename, because most of the time we are interested in looking
at the resulting tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Applying Andrew's latest patch-bomb showed us failing miserably if a new
subdirectory needed to be created.. That said, it's uncommon enough
that it's worth optimistically assuming it won't be needed, and then
creating the subdirectories only on failure.
|
|
Diffs with only mode changes didn't pass through git-apply --stat.
[ Linus' note: they did for me, on my ppc64, where division by zero just
silently returns zero. Duh. ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Pure mode changes won't have the file-name in the extended header lines,
so make sure we pick it up from the default name from the "diff --git"
line.
|
|
Sine git only saves the 'x' bit, we shouldn't compare the stat contents
directly.
|
|
Missing argument for error() function. We should really use the
gcc printf format checking capabilities.
|
|
A meaningful (ie non-empty) git patch always has more information in the
header than just the "diff --git" line itself: it needs to have either a
patch associated with it (which implies "---" and "+++" lines in the
header) or it needs to have rename/copy/delete/create information in it.
Just ignore git patches which have no change information. Otherwise we'll
end up with a patch that doesn't have filenames etc filled in, and we'll
be unhappy.
|
