Lots of die() calls did not actually report the kind of error, which
can leave the user confused as to the real problem. Use die_errno()
where we check a system/library call that sets errno on failure, or
one of the following that wrap such calls:
Function Passes on error from
-------- --------------------
odb_pack_keep open
read_ancestry fopen
read_in_full xread
strbuf_read xread
strbuf_read_file open or strbuf_read_file
strbuf_readlink readlink
write_in_full xwrite
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change calls to die(..., strerror(errno)) to use the new die_errno().
In the process, also make slight style adjustments: at least state
_something_ about the function that failed (instead of just printing
the pathname), and put paths in single quotes.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are a few remaining ones, but this fixes the trivial ones. It boils
down to two main issues that sparse complains about:
- warning: Using plain integer as NULL pointer
Sparse doesn't like you using '0' instead of 'NULL'. For various good
reasons, not the least of which is just the visual confusion. A NULL
pointer is not an integer, and that whole "0 works as NULL" is a
historical accident and not very pretty.
A few of these remain: zlib is a total mess, and Z_NULL is just a 0.
I didn't touch those.
- warning: symbol 'xyz' was not declared. Should it be static?
Sparse wants to see declarations for any functions you export. A lack
of a declaration tends to mean that you should either add one, or you
should mark the function 'static' to show that it's in file scope.
A few of these remain: I only did the ones that should obviously just
be made static.
That 'wt_status_submodule_summary' one is debatable. It has a few related
flags (like 'wt_status_use_color') which _are_ declared, and are used by
builtin-commit.c. So maybe we'd like to export it at some point, but it's
not declared now, and not used outside of that file, so 'static' it is in
this patch.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Simplify the argh printing by simply calling usage_argh() if the option
can take an argument. Update macros defined in parse-options.h to set
the PARSE_OPT_NOARG flag.
The only other user of custom non-argument taking options is git-apply
(in this case OPTION_BOOLEAN for deprecated options). Update it to set
the PARSE_OPT_NOARG flag.
Thanks to Ren辿 Scharfe for the suggestion and starter patch.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Reviewd-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit dbd0f5c (Files given on the command line are relative to $cwd,
2008-08-06) introduced parse_options_fix_filename() as a minimal fix.
OPT_FILENAME is intended to be a more robust fix for the same issue.
OPT_FILENAME and its associated enum OPTION_FILENAME are used to
represent filename options within the parse options API.
This option is similar to OPTION_STRING. If --no is prefixed to the
option the filename is unset. If no argument is given and the default
value is set, the filename is set to the default value. The difference
is that the filename is prefixed with the prefix passed to
parse_options() (or parse_options_start()).
Update git-apply, git-commit, git-fmt-merge-msg, and git-tag to use
OPT_FILENAME with their filename options. Also, rename
parse_options_fix_filename() to fix_filename() as it is no longer
extern.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To give OPT_FILENAME the prefix, we pass the prefix to parse_options()
which passes the prefix to parse_options_start() which sets the prefix
member of parse_opts_ctx accordingly. If there isn't a prefix in the
calling context, passing NULL will suffice.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When there are duplicated slashes in pathnames, like this:
--- a/perl//Git.pm
+++ b/perl//Git.pm
@@ -1358,3 +1358,4 @@
1; # Famous last words
+# test
the paths gleaned from the patch header won't be found in the index and
cause "apply --index" and "apply --cached" to fail.
Fix this by squashing the duplicated slashes upon input.
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit dbd0f5c7 (Files given on the command line are relative to $cwd,
2008-08-06) only fixed git-commit and git-tag. But, git-apply and
git-fmt-merge-msg didn't get the update and exhibit the same behavior.
Fix them and add tests for "apply --build-fake-ancestor" and
"fmt-merge-msg -F".
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This helps to notice when something's going wrong, especially on
systems which lock open files.
I used the following criteria when selecting the code for replacement:
- it was already printing a warning for the unlink failures
- it is in a function which already printing something or is
called from such a function
- it is in a static function, returning void and the function is only
called from a builtin main function (cmd_)
- it is in a function which handles emergency exit (signal handlers)
- it is in a function which is obvously cleaning up the lockfiles
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Example correct diff generated by `diff -M -B' might look like this:
diff --git a/file1 b/file2
similarity index 100%
rename from file1
rename to file2
diff --git a/file2 b/file1
similarity index 100%
rename from file2
rename to file1
Information about removing `file2' comes after information about creation
of new `file2' (renamed from `file1'). Existing implementation isn't able to
apply such patch, because it has to know in advance which files will be
removed.
This patch populates fn_table with information about removal of files
before calling check_patch() for each patch to be applied.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Example correct diff generated by `diff -M -B' might look like this:
diff --git a/file1 b/file2
similarity index 100%
rename from file1
rename to file2
diff --git a/file2 b/file1
similarity index 100%
rename from file2
rename to file1
Information about removing `file2' comes after information about creation
of new `file2' (renamed from `file1'). Existing implementation isn't able to
apply such patch, because it has to know in advance which files will be
removed.
This patch populates fn_table with information about removal of files
before calling check_patch() for each patch to be applied.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The options "--binary" and "--allow-binary-replacement" of
git-apply are no-op and maintained for backward compatibility,
so avoid to show them in the short help screen.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Swap function argument pair (length, string) into (string, length) to
conform with the commonly used order inside the GIT source code.
Also, add a note about this fact into the coding guidelines.
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When 'tpatch' was initialized successfully, st_mode was already taken
from the previous diff. We should not try to override it with data
from an lstat() that was never called.
This is a companion patch to 7a07841(git-apply: handle a patch that
touches the same path more than once better).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
R. Tyler Ballance reported a mysterious transient repository corruption;
after much digging, it turns out that we were not catching and reporting
memory allocation errors from some calls we make to zlib.
This one _just_ wraps things; it doesn't do the "retry on low memory
error" part, at least not yet. It is an independent issue from the
reporting. Some of the errors are expected and passed back to the caller,
but we die when zlib reports it failed to allocate memory for now.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous "parse-opt"ification broke git-apply reading from the
standard input. "git apply A - C <B" is supposed to read patches from
files A, B and C in this order.
Before "parse-opt"ification, we used be able to:
git apply --stat - --apply <A B
to read the patch from file A, showing only the diffstat, and then read the
patch from file B, showing the diffstat and actually applying it. Even
with this fix we cannot do that anymore, but that is so crazy use case I
do not think anybody sane relied on such a broken behaviour.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A git patch that does not change the executable bit records the mode bits
on its "index" line. "git apply" used to interpret this mode exactly the
same way as it interprets the mode recorded on "new mode" line, as the
wish by the patch submitter to set the mode to the one recorded on the
line.
The reason the mode does not agree between the submitter and the receiver
in the first place is because there is _another_ commit that only appears
on one side but not the other since their histories diverged, and that
commit changes the mode. The patch has "index" line but not "new mode"
line because its change is about updating the contents without affecting
the mode. The application of such a patch is an explicit wish by the
submitter to only cherry-pick the commit that updates the contents without
cherry-picking the commit that modifies the mode. Viewed this way, the
current behaviour is problematic, even though the command does warn when
the mode of the path being patched does not match this mode, and a careful
user could detect this inconsistencies between the patch submitter and the
patch receiver.
This changes the semantics of the mode recorded on the "index" line;
instead of interpreting it as the submitter's wish to set the mode to the
recorded value, it merely informs what the mode submitter happened to
have, and the presense of the "index" line is taken as submitter's wish to
keep whatever the mode is on the receiving end.
This is based on the patch originally done by Alexander Potashev with a
minor fix; the tests are mine.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The only incompatible change is that the user how have to use '--'
before a patch file if it is named "--build-fake-ancestor=something".
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was already what 'git apply' did in read_old_data(), just export it
as a real function, and make it be more generic.
In particular, this handles the case of the lstat() st_size data not
matching the readlink() return value properly (which apparently happens
at least on NTFS under Linux). But as a result of this you could also
use the new function without even knowing how big the link is going to
be, and it will allocate an appropriately sized buffer.
So we pass in the st_size of the link as just a hint, rather than a
fixed requirement.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace them with mksnpath/git_snpath and a local buffer
for the resulting string.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many call sites use strbuf_init(&foo, 0) to initialize local
strbuf variable "foo" which has not been accessed since its
declaration. These can be replaced with a static initialization
using the STRBUF_INIT macro which is just as readable, saves a
function call, and takes up fewer lines.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We carefully verify that the input to git-apply is sane,
including cross-checking that the filenames we see in "+++"
headers match what was provided on the command line of "diff
--git". When --directory is used, however, we ended up
comparing the unadorned name to one with the prepended root,
causing us to complain about a mismatch.
We simply need to prepend the root directory, if any, when
pulling the name out of the git header.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This typo led to stack corruption for lines with whitespace fixes
and length > 1024.
Signed-off-by: Imre Deak <imre.deak@gmail.com>
Looks-good-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Besides, it fixes a memleak (builtin-rm.c) and accidental change of
the input const argument (builtin-merge-recursive.c).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This allows --include=pathspec, similar to --exclude=pathspec.
The rule when one or both of these are used is that the include/exclude
patterns are examined in the order they are given on the command line, and
the first match determines if a patch to each path is used or not. Hence:
$ git apply --include='specific.h' --exclude='*.h' <diff
would apply the patch to specific.h header file, but all other patches in
the input file to other header files are ignored. A patch to a path that
does not match any include/exclude pattern is used by default if there is
no include pattern on the command line, and ignored if there is any
include pattern.
This originally came from Joe Perches, but both the design of the
semantics and the implementation have been redone complately.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a mechanical conversion of all '*.c' files with:
s/((?:die|error|warning)\("git)-(\S+:)/$1 $2/;
The result was manually inspected and no false positive was found.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
User notifications are presented as 'git cmd', and code comments
are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'.
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even after a handfle attempts, match_beginning logic still has corner
cases:
1bf1a85 (apply: treat EOF as proper context., 2006-05-23)
65aadb9 (apply: force matching at the beginning., 2006-05-24)
4be6096 (apply --unidiff-zero: loosen sanity checks ..., 2006-09-17)
ee5a317 (Fix "git apply" to correctly enforce "match ..., 2008-04-06)
This is a tricky piece of code.
We still incorrectly enforce "match_beginning" for -U0 matches.
I noticed this while trying out an example sequence from Clemens Buchacher:
$ echo a >victim
$ git add victim
$ echo b >>victim
$ git diff -U0 >patch
$ cat patch
diff --git i/victim w/victim
index 7898192..422c2b7 100644
--- i/victim
+++ w/victim
@@ -1,0 +2 @@ a
+b
$ git apply --cached --unidiff-zero <patch
$ git show :victim
b
a
The change inserts a new line before the second line, but we insist it to
be applied at the beginning. As the result, the code refuses to apply it
at the original offset, and we end up adding the line at the beginning.
Updates to the test script are by Clemens Buchacher.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The name path_list was correct for the first usage of that data structure,
but it really is a general-purpose string list.
$ perl -i -pe 's/path-list/string-list/g' $(git grep -l path-list)
$ perl -i -pe 's/path_list/string_list/g' $(git grep -l path_list)
$ git mv path-list.h string-list.h
$ git mv path-list.c string-list.c
$ perl -i -pe 's/has_path/has_string/g' $(git grep -l has_path)
$ perl -i -pe 's/path/string/g' string-list.[ch]
$ git mv Documentation/technical/api-path-list.txt \
Documentation/technical/api-string-list.txt
$ perl -i -pe 's/strdup_paths/strdup_strings/g' $(git grep -l strdup_paths)
... and then fix all users of string-list to access the member "string"
instead of "path".
Documentation/technical/api-string-list.txt needed some rewrapping, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you misuse a git command, you are shown the usage string.
But this is currently shown in the dashed form. So if you just
copy what you see, it will not work, when the dashed form
is no longer supported.
This patch makes git commands show the dash-less version.
For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
generates a dash-less usage string now.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
7ebd52a (Merge branch 'dz/apply-again', 2008-07-01) taught "git-apply" to
grok a (non-git) patch that is a concatenation of separate patches that
touch the same file number of times, by recording the postimage of patch
application of previous round and using it as the preimage for later
rounds.
This "incremental" mode of patch application fundamentally contradicts
with the way git rename/copy patches are designed. When a git patch talks
about a file A getting modified, and a new file B created out of A, like
this:
diff --git a/A b/A
--- a/A
+++ b/A
... change text here ...
diff --git a/A b/B
copy from A
copy to B
--- a/A
+++ b/B
... change text here ...
the second change to produce B does not depend on what is done to A with
the first change in any way. This is explicitly done so for reviewability
of individual patches.
With this commit, we do not look at 'fn_table' that records the postimage
of previous round when applying a patch to produce a new file out of an
existing file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Applying a patch in the directory that is different from what the patch
records is done with --directory option in GNU diff. The --root option we
introduced previously does the same, and we can call it the same way to
give users more familiar feel.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a patch modifies the last line of a file that previously had no
terminating '\n', it looks like
-old text
\ No newline at end of file
+new text
Hence, a '\' line does not signal the end of the hunk. This modifies
'git apply --recount' to take this into account.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The end of a string is string[length-1], not string[length+1].
I pointed it out during the review, but I forgot about it when applying the
patch. This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With "git apply --root=<root>", all file names in the patch are prepended
with <root>. If a "-p" value was given, the paths are stripped _before_
prepending <root>.
Wished for by HPA.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sometimes, the easiest way to fix up a patch is to edit it directly, even
adding or deleting lines. Now, many people are not as divine as certain
benevolent dictators as to update the hunk headers correctly at the first
try.
So teach the tool to do it for us.
[jc: with tests]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When working with a lot of people who backport patches all day long, every
once in a while I get a patch that modifies the same file more than once
inside the same patch. git-apply either fails if the second change relies
on the first change or silently drops the first change if the second change
is independent.
The silent part is the scary scenario for us. Also this behaviour is
different from the patch-utils.
I have modified git-apply to create a table of the filenames of files it
modifies such that if a later patch chunk modifies a file in the table it
will buffer the previously changed file instead of reading the original file
from disk.
Logic has been put in to handle creations/deletions/renames/copies. All the
relevant tests of git-apply succeed.
A new test has been added to cover the cases I addressed.
The fix is relatively straight-forward.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function name was too bland and not explicit enough as to what it is
checking. Split it into two, and call the one that checks if there is a
whitespace breakage "ws_check()", and call the other one that checks and
emits the line after color coding "ws_check_emit()".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we see no context nor deleted line in the patch, we used to declare
that the patch creates a new file. But some people create an empty file
and then apply a patch to it. Similarly, a patch that delete everything
is not a deletion patch either.
This commit corrects these two issues. Together with the previous commit,
it allows a diff between an empty file and a line-ful file to be treated
as both creation patch and "add stuff to an existing empty file",
depending on the context. A new test t4126 demonstrates the fix.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A patch from a foreign SCM (or plain "diff" output) often have both
preimage and postimage filename on ---/+++ lines even for a patch that
creates a new file. However, when there is a filename for preimage, we
used to insist the file to exist (either in the work tree and/or in the
index). When we cannot be sure by parsing the patch that it is not a
creation patch, we shouldn't complain when if there is no such a file.
This commit fixes the logic.
Refactor the code that validates the preimage file into a separate
function while we are at it, as it is getting rather big.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git_config() only had a function parameter, but no callback data
parameter. This assumes that all callback functions only modify
global variables.
With this patch, every callback gets a void * parameter, and it is hoped
that this will help the libification effort.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is the base for making symlink detection in the middle fo a pathname
saner and (much) more efficient.
Under various loads, we want to verify that the full path leading up to a
filename is a real directory tree, and that when we successfully do an
'lstat()' on a filename, we don't get a false positive due to a symlink in
the middle of the path that git should have seen as a symlink, not as a
normal path component.
The 'has_symlink_leading_path()' function already did this, and cached
a single level of symlink information, but didn't cache the _lack_ of a
symlink, so the normal behaviour was actually the wrong way around, and we
ended up doing an 'lstat()' on each path component to check that it was a
real directory.
This caches the last detected full directory and symlink entries, and
speeds up especially deep directory structures a lot by avoiding to
lstat() all the directories leading up to each entry in the index.
[ This can - and should - probably be extended upon so that we eventually
never do a bare 'lstat()' on any path entries at *all* when checking the
index, but always check the full path carefully. Right now we do not
generally check the whole path for all our normal quick index
revalidation.
We should also make sure that we're careful about all the invalidation,
ie when we remove a link and replace it by a directory we should
invalidate the symlink cache if it matches (and vice versa for the
directory cache).
But regardless, the basic function needs to be sane to do that. The old
'has_symlink_leading_path()' was not capable enough - or indeed the code
readable enough - to really do that sanely. So I'm pushing this as not
just an optimization, but as a base for further work. ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a patch can't be opened (it doesn't exist, there are permission
problems, etc.) we get the usage text, which is not a proper indication of
failure.
Signed-off-by: Alberto Bertogli <albertito@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast