summaryrefslogtreecommitdiff
path: root/builtin-apply.c
AgeCommit message (Collapse)AuthorFilesLines
2010-02-03Typofixes outside documentation areaLibravatar Junio C Hamano1-1/+1
begining -> beginning canonicalizations -> canonicalization comand -> command dewrapping -> unwrapping dirtyness -> dirtiness DISCLAMER -> DISCLAIMER explicitely -> explicitly feeded -> fed impiled -> implied madatory -> mandatory mimick -> mimic preceeding -> preceding reqeuest -> request substition -> substitution Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge branch 'ag/patch-header-verify'Libravatar Junio C Hamano1-1/+1
* ag/patch-header-verify: builtin-apply.c: fix the --- and +++ header filename consistency check
2010-01-20Merge branch 'ag/maint-apply-too-large-p'Libravatar Junio C Hamano1-2/+9
* ag/maint-apply-too-large-p: builtin-apply.c: Skip filenames without enough components
2010-01-18builtin-apply.c: fix the --- and +++ header filename consistency checkLibravatar Andreas Gruenbacher1-1/+1
gitdiff_verify_name() only did a filename prefix check because of an off-by-one error. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-18builtin-apply.c: Skip filenames without enough componentsLibravatar Andreas Gruenbacher1-2/+9
find_name() wrongly returned the whole filename for filenames without enough leading pathname components (e.g., when applying a patch to a top-level file with -p2). Include the -p value used in the error message when no filenames can be found. [jc: squashed a test from Nanako Shiraishi] Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-13Merge branch 'nd/sparse'Libravatar Junio C Hamano1-1/+1
* nd/sparse: (25 commits) t7002: test for not using external grep on skip-worktree paths t7002: set test prerequisite "external-grep" if supported grep: do not do external grep on skip-worktree entries commit: correctly respect skip-worktree bit ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID tests: rename duplicate t1009 sparse checkout: inhibit empty worktree Add tests for sparse checkout read-tree: add --no-sparse-checkout to disable sparse checkout support unpack-trees(): ignore worktree check outside checkout area unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout unpack-trees.c: generalize verify_* functions unpack-trees(): add CE_WT_REMOVE to remove on worktree alone Introduce "sparse checkout" dir.c: export excluded_1() and add_excludes_from_file_1() excluded_1(): support exclude files in index unpack-trees(): carry skip-worktree bit over in merged_entry() Read .gitignore from index if it is skip-worktree Avoid writing to buffer in add_excludes_from_file_1() ... Conflicts: .gitignore Documentation/config.txt Documentation/git-update-index.txt Makefile entry.c t/t7002-grep.sh
2009-12-14ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALIDLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Previously CE_MATCH_IGNORE_VALID flag is used by both valid and skip-worktree bits. While the two bits have similar behaviour, sharing this flag means "git update-index --really-refresh" will ignore skip-worktree while it should not. Instead another flag is introduced to ignore skip-worktree bit, CE_MATCH_IGNORE_VALID only applies to valid bit. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-26builtin-apply.c: pay attention to -p<n> when determining the nameLibravatar Junio C Hamano1-2/+3
The patch structure has def_name component that is used to validate the sanity of a "diff --git" patch by checking pathnames that appear on the patch header lines for consistency. The git_header_name() function is used to compute this out of "diff --git a/... b/..." line, but the code always stripped one level of prefix (i.e. "a/" and "b/"), without paying attention to -p<n> option. Code in find_name() function that parses other lines in the patch header (e.g. "--- a/..." and "+++ b/..." lines) however did strip the correct number of leading paths prefixes, and the sanity check between these computed values failed. Teach git_header_name() to honor -p<n> option like find_name() function does. Found and reported by Steven J. Murdoch who also wrote tests. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-15Merge branch 'jc/maint-blank-at-eof' into maintLibravatar Junio C Hamano1-19/+42
* jc/maint-blank-at-eof: diff -B: colour whitespace errors diff.c: emit_add_line() takes only the rest of the line diff.c: split emit_line() from the first char and the rest of the line diff.c: shuffling code around diff --whitespace: fix blank lines at end core.whitespace: split trailing-space into blank-at-{eol,eof} diff --color: color blank-at-eof diff --whitespace=warn/error: fix blank-at-eof check diff --whitespace=warn/error: obey blank-at-eof diff.c: the builtin_diff() deals with only two-file comparison apply --whitespace: warn blank but not necessarily empty lines at EOF apply --whitespace=warn/error: diagnose blank at EOF apply.c: split check_whitespace() into two apply --whitespace=fix: detect new blank lines at eof correctly apply --whitespace=fix: fix handling of blank lines at the eof
2009-09-15Merge branch 'jc/maint-1.6.0-blank-at-eof' (early part) into ↵Libravatar Junio C Hamano1-19/+42
jc/maint-blank-at-eof * 'jc/maint-1.6.0-blank-at-eof' (early part): diff --whitespace: fix blank lines at end core.whitespace: split trailing-space into blank-at-{eol,eof} diff --color: color blank-at-eof diff --whitespace=warn/error: fix blank-at-eof check diff --whitespace=warn/error: obey blank-at-eof diff.c: the builtin_diff() deals with only two-file comparison apply --whitespace: warn blank but not necessarily empty lines at EOF apply --whitespace=warn/error: diagnose blank at EOF apply.c: split check_whitespace() into two apply --whitespace=fix: detect new blank lines at eof correctly apply --whitespace=fix: fix handling of blank lines at the eof
2009-09-04apply --whitespace: warn blank but not necessarily empty lines at EOFLibravatar Junio C Hamano1-2/+4
The whitespace error of adding blank lines at the end of file should trigger if you added a non-empty line at the end, if the contents of the line is full of whitespaces. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-04apply --whitespace=warn/error: diagnose blank at EOFLibravatar Junio C Hamano1-9/+18
"git apply" strips new blank lines at EOF under --whitespace=fix option, but neigher --whitespace=warn nor --whitespace=error paid any attention to these errors. Introduce a new whitespace error class, blank-at-eof, to make the whitespace error handling more consistent. The patch adds a new "linenr" field to the struct fragment in order to record which line the hunk started in the input file, but this is needed solely for reporting purposes. The detection of this class of whitespace errors cannot be done while parsing a patch like we do for all the other classes of whitespace errors. It instead has to wait until we find where to apply the hunk, but at that point, we do not have an access to the original line number in the input file anymore, hence the new field. Depending on your point of view, this may be a bugfix that makes warn and error in line with fix. Or you could call it a new feature. The line between them is somewhat fuzzy in this case. Strictly speaking, triggering more errors than before is a change in behaviour that is not backward compatible, even though the reason for the change is because the code was not checking for an error that it should have. People who do not want added blank lines at EOF to trigger an error can disable the new error class. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-04apply.c: split check_whitespace() into twoLibravatar Junio C Hamano1-9/+15
This splits the logic to record the presence of whitespace errors out of the check_whitespace() function, which checks and then records. The new function, record_ws_error(), can be used by the blank-at-eof check that does not use ws_check() logic to report its findings in the same output format. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-04apply --whitespace=fix: detect new blank lines at eof correctlyLibravatar Junio C Hamano1-0/+6
The command tries to strip blank lines at the end of the file added by a patch. It is done by first detecting if a hunk in patch has additional blank lines at the end of itself, and if so checking if such a hunk applies at the end of file. This patch addresses a bug in the logic to implement the former (the previous one addressed a bug in the latter). If the original ends with blank lines, often the patch hunk ends like this: @@ -l,5 +m,7 @@$ _context$ _context$ -deleted$ +$ +$ +$ _$ _$ where _ stands for SP and $ shows a end-of-line. This example patch adds three trailing blank lines, but the code fails to notice it, because it only pays attention to added blank lines at the very end of the hunk. In this example, the three added blank lines do not appear textually at the end in the patch, even though you can see that they are indeed added at the end, if you rearrange the diff like this: @@ -l,5 +m,7 @@$ _context$ _context$ -deleted$ _$ _$ +$ +$ +$ The fix is not to reset the number of (candidate) added blank lines at the end when the loop sees a context line that is empty. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-04apply --whitespace=fix: fix handling of blank lines at the eofLibravatar Junio C Hamano1-1/+1
b94f2ed (builtin-apply.c: make it more line oriented, 2008-01-26) broke the logic used to detect if a hunk adds blank lines at the end of the file. With the new code after that commit: - img holds the contents of the file that the hunk is being applied to; - preimage has the lines the hunk expects to be in img; and - postimage has the lines the hunk wants to update the part in img that corresponds to preimage with. and we need to compare if the last line of preimage (not postimage) matches the last line of img to see if the hunk applies at the end of the file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-01builtin-apply.c: get rid of an unnecessary use of temporary arrayLibravatar Junio C Hamano1-8/+6
Instead of allocating a temporary array imglen[], copying contents to it from another array img->line[], and then using imglen[], use the value from img->line[], whose value does not change during the whole process. This incidentally removes a use of C99 variable length array, which some older compilers apparently are not happy with. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-21Merge branch 'gb/apply-ignore-whitespace'Libravatar Junio C Hamano1-7/+166
* gb/apply-ignore-whitespace: git apply: option to ignore whitespace differences
2009-08-05git apply: option to ignore whitespace differencesLibravatar Giuseppe Bilotta1-7/+166
Introduce --ignore-whitespace option and corresponding config bool to ignore whitespace differences while applying patches, akin to the 'patch' program. 'git am', 'git rebase' and the bash git completion are made aware of this option. Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-11apply: notice creation/removal patches produced by GNU diffLibravatar Junio C Hamano1-1/+81
Unified context patch generated by GNU diff has UNIX epoch timestamp on the side that does not exist when the patch is about a creation or a deletion event. Notice this convention when reading a non-git diff. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-06Merge branch 'tr/die_errno'Libravatar Junio C Hamano1-6/+6
* tr/die_errno: Use die_errno() instead of die() when checking syscalls Convert existing die(..., strerror(errno)) to die_errno() die_errno(): double % in strerror() output just in case Introduce die_errno() that appends strerror(errno) to die()
2009-06-27Use die_errno() instead of die() when checking syscallsLibravatar Thomas Rast1-3/+3
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>
2009-06-27Convert existing die(..., strerror(errno)) to die_errno()Libravatar Thomas Rast1-3/+3
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>
2009-06-20Fix various sparse warnings in the git source codeLibravatar Linus Torvalds1-1/+1
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>
2009-06-06parse-options: simplify usage argh handlingLibravatar Stephen Boyd1-2/+4
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>
2009-05-31Merge branch 'sb/opt-filename'Libravatar Junio C Hamano1-5/+2
* sb/opt-filename: parse-opts: add OPT_FILENAME and transition builtins parse-opts: prepare for OPT_FILENAME Conflicts: builtin-log.c
2009-05-31Merge branch 'mm/apply-double-slash'Libravatar Junio C Hamano1-6/+20
* mm/apply-double-slash: apply: handle filenames with double slashes better
2009-05-29Merge branch 'sb/maint-1.6.2-opt-filename-fix'Libravatar Junio C Hamano1-0/+4
* sb/maint-1.6.2-opt-filename-fix: apply, fmt-merge-msg: use relative filenames commit: -F overrides -t
2009-05-25parse-opts: add OPT_FILENAME and transition builtinsLibravatar Stephen Boyd1-4/+1
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>
2009-05-25parse-opts: prepare for OPT_FILENAMELibravatar Stephen Boyd1-1/+1
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>
2009-05-25Merge branch 'master' into sb/opt-filenameLibravatar Junio C Hamano1-15/+14
* master: (654 commits) http-push.c::remove_locks(): fix use after free t/t3400-rebase.sh: add more tests to help migrating git-rebase.sh to C post-receive-email: hooks.showrev: show how to include both web link and patch MinGW: Fix compiler warning in merge-recursive MinGW: Add a simple getpass() MinGW: use POSIX signature of waitpid() MinGW: the path separator to split GITPERLLIB is ';' on Win32 MinGW: Scan for \r in addition to \n when reading shbang lines gitweb: Sanitize title attribute in format_subject_html Terminate argv with NULL before calling setup_revisions() doc/git-rebase.txt: remove mention of multiple strategies git-send-email: Handle quotes when parsing .mailrc files git-svn: add --authors-prog option git-svn: Set svn.authorsfile if it is passed to git svn clone git-svn: Correctly report max revision when following deleted paths git-svn: Fix for svn paths removed > log-window-size revisions ago git-svn testsuite: use standard configuration for Subversion tools grep: fix word-regexp colouring completion: use git rev-parse to detect bare repos Cope better with a _lot_ of packs ...
2009-05-24apply: handle filenames with double slashes betterLibravatar Michal Marek1-6/+20
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>
2009-05-23apply, fmt-merge-msg: use relative filenamesLibravatar Stephen Boyd1-0/+4
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>
2009-04-29replace direct calls to unlink(2) with unlink_or_warnLibravatar Alex Riesen1-2/+2
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>
2009-04-20builtin-apply: keep information about files to be deletedLibravatar Michał Kiedrowicz1-7/+46
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>
2009-04-16git-apply: fix option descriptionLibravatar Ulrich Windl1-1/+1
Do not use non ASCII single quote. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-15builtin-apply: keep information about files to be deletedLibravatar Michał Kiedrowicz1-7/+46
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>
2009-03-23builtin-apply: use warning() instead of fprintf(stderr, "warning: ")Libravatar Miklos Vajna1-8/+7
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-18apply: hide unused options from short helpLibravatar Michele Ballabio1-4/+4
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>
2009-03-18apply: consistent spelling of "don't"Libravatar Michele Ballabio1-1/+1
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-09lstat_cache(): swap func(length, string) into func(string, length)Libravatar Kjetil Barvik1-1/+1
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>
2009-02-04Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: User-manual: "git stash <comment>" form is long gone add test-dump-cache-tree in Makefile fix typo in Documentation apply: fix access to an uninitialized mode variable, found by valgrind Conflicts: Makefile
2009-02-03Merge branch 'maint-1.6.0' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.6.0: User-manual: "git stash <comment>" form is long gone add test-dump-cache-tree in Makefile fix typo in Documentation apply: fix access to an uninitialized mode variable, found by valgrind
2009-02-03apply: fix access to an uninitialized mode variable, found by valgrindLibravatar Johannes Schindelin1-1/+1
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>
2009-01-31Merge branch 'jc/maint-apply-fix'Libravatar Junio C Hamano1-1/+1
* jc/maint-apply-fix: builtin-apply.c: do not set bogus mode in check_preimage() for deleted path
2009-01-28builtin-apply.c: do not set bogus mode in check_preimage() for deleted pathLibravatar Junio C Hamano1-1/+1
If it is deleted, it is deleted. Do not set the current mode to it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-21Merge branch 'lt/maint-wrap-zlib'Libravatar Junio C Hamano1-2/+3
* lt/maint-wrap-zlib: Wrap inflate and other zlib routines for better error reporting Conflicts: http-push.c http-walker.c sha1_file.c
2009-01-17Merge branch 'mv/apply-parse-opt'Libravatar Junio C Hamano1-126/+140
* mv/apply-parse-opt: Resurrect "git apply --flags -" to read from the standard input parse-opt: migrate builtin-apply.
2009-01-13Merge branch 'ap/maint-apply-modefix' into maintLibravatar Junio C Hamano1-1/+3
* ap/maint-apply-modefix: builtin-apply: prevent non-explicit permission changes
2009-01-11Wrap inflate and other zlib routines for better error reportingLibravatar Linus Torvalds1-2/+3
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>
2009-01-09Resurrect "git apply --flags -" to read from the standard inputLibravatar Junio C Hamano1-14/+5
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-18 02:13:17 +0000