summaryrefslogtreecommitdiff
path: root/builtin/apply.c
AgeCommit message (Collapse)AuthorFilesLines
2012-07-15Merge branch 'jc/apply-3way'Libravatar Junio C Hamano1-117/+440
"git apply" learned to wiggle the base version and perform three-way merge when a patch does not exactly apply to the version you have. * jc/apply-3way: apply: tests for the --3way option apply: document --3way option apply: allow rerere() to work on --3way results apply: register conflicted stages to the index apply: --3way with add/add conflict apply: move verify_index_match() higher apply: plug the three-way merge logic in apply: fall back on three-way merge apply: accept -3/--3way command line option apply: move "already exists" logic to check_to_create() apply: move check_to_create_blob() closer to its sole caller apply: further split load_preimage() apply: refactor "previous patch" logic apply: split load_preimage() helper function out apply: factor out checkout_target() helper function apply: refactor read_file_or_gitlink() apply: clear_image() clears things a bit more apply: a bit more comments on PATH_TO_BE_DELETED apply: fix an incomplete comment in check_patch()
2012-07-09apply: allow rerere() to work on --3way resultsLibravatar Junio C Hamano1-0/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: register conflicted stages to the indexLibravatar Junio C Hamano1-6/+60
Now we have all the necessary logic to fall back on three-way merge when the patch does not cleanly apply, insert the conflicted entries to the index as appropriate. This obviously triggers only when the "--index" option is used. When we fall back to three-way merge and some of the merges fail, just like the case where the "--reject" option was specified and we had to write some "*.rej" files out for unapplicable patches, exit the command with non-zero status without showing the diffstat and summary. Otherwise they would make the list of problematic paths scroll off the display. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: --3way with add/add conflictLibravatar Junio C Hamano1-8/+62
When a patch wants to create a path, but we already have it in our current state, pretend as if the patch and we independently added the same path and cause add/add conflict, so that the user can resolve it just like "git merge" in the same situation. For that purpose, implement load_current() in terms of the load_patch_target() helper introduced earlier to read the current contents from the path given by patch->new_name (patch->old_name is NULL for a creation patch). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: move verify_index_match() higherLibravatar Junio C Hamano1-10/+10
We will be adding another caller of this function in a later patch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: plug the three-way merge logic inLibravatar Junio C Hamano1-3/+50
When a patch does not apply to what we have, but we know the preimage the patch was made against, we apply the patch to the preimage to compute what the patch author wanted the result to look like, and attempt a three-way merge between the result and our version, using the intended preimage as the base version. When we are applying the patch using the index, we would additionally need to add the object names of these three blobs involved in the merge, which is not yet done in this step, but we add a field to "struct patch" so that later write-out step can use it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: fall back on three-way mergeLibravatar Junio C Hamano1-1/+45
Grab the preimage blob the patch claims to be based on out of the object store, apply the patch, and then call three-way-merge function. This step still does not plug the actual three-way merge logic yet, but we are getting there. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: accept -3/--3way command line optionLibravatar Junio C Hamano1-2/+23
Begin teaching the three-way merge fallback logic "git am -3" uses to the underlying "git apply". It only implements the command line parsing part, and does not do anything interesting yet, other than making sure that "--reject" and "--3way" are not given together, and making "--3way" imply "--index". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: move "already exists" logic to check_to_create()Libravatar Junio C Hamano1-11/+29
The check_to_create_blob() function used to check only the case where we are applying to the working tree. Rename the function to check_to_create() and make it also responsible for checking the case where we apply to the index. Also make its caller responsible for issuing an error message. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: move check_to_create_blob() closer to its sole callerLibravatar Junio C Hamano1-23/+23
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: further split load_preimage()Libravatar Junio C Hamano1-19/+40
load_preimage() is very specific to grab the current contents for the path given by patch->old_name. Split the logic that grabs the contents for a path out of it into a separate load_patch_target() function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: refactor "previous patch" logicLibravatar Junio C Hamano1-26/+56
The code to grab the result of application of a previous patch in the input was mixed with error message generation for a case where a later patch tries to modify contents of a path that has been removed. The same code is duplicated elsewhere in the code. Introduce a helper to clarify what is going on. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: split load_preimage() helper function outLibravatar Junio C Hamano1-3/+12
Given a patch for a single path, the function apply_data() reads the preimage in core, and applies the change represented in the patch. Separate out the first part that reads the preimage into a separate helper function load_preimage(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: factor out checkout_target() helper functionLibravatar Junio C Hamano1-7/+13
When a patch wants to touch a path, if the path exists in the index but is missing in the working tree, "git apply --index" checks out the file to the working tree from the index automatically and then applies the patch. Split this logic out to a separate helper function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: refactor read_file_or_gitlink()Libravatar Junio C Hamano1-7/+11
Reading a blob out of the object store does not have to require that the caller has a cache entry for it. Create a read_blob_object() helper function that takes the object name and mode, and use it to reimplement the original function as a thin wrapper to it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: clear_image() clears things a bit moreLibravatar Junio C Hamano1-2/+2
The clear_image() function did not clear the line table in the image structure; this does not matter for the current callers, as the function is only called from the codepaths that deal with binary patches where the line table is never populated, and the codepaths that do populate the line table free it themselves. But it will start to matter when we introduce a codepath to retry a failed patch, so make sure it clears and frees everything. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: a bit more comments on PATH_TO_BE_DELETEDLibravatar Junio C Hamano1-2/+8
The code is littered with to_be_deleted() whose purpose is not so clear. Describe where it matters. Also remove an extra space before "#define" that snuck in by mistake at 7fac0ee (builtin-apply: keep information about files to be deleted, 2009-04-11). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: fix an incomplete comment in check_patch()Libravatar Junio C Hamano1-9/+15
This check is not only about type-change (for which it would be sufficient to check only was_deleted()) but is also about a swap rename. Otherwise to_be_deleted() check is not justified. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-01i18n: apply: split to fix a partial i18n messageLibravatar Jiang Xin1-4/+12
The 4th arg of "new mode (%o) of %s does not match old mode (%o)%s%s" is blank string or string " of ". Even mark the string " of " for a complete i18n, this message is still hard to translate right. Split it into two slight different messages would make l10n teams happy. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-17Merge branch 'nd/i18n-parseopt'Libravatar Junio C Hamano1-31/+31
Text from "git cmd --help" are getting prepared for i18n. By Nguyễn Thái Ngọc Duy * nd/i18n-parseopt: i18n: apply: mark parseopt strings for translation i18n: parseopt: lookup help and argument translations when showing usage
2012-05-08i18n: apply: mark parseopt strings for translationLibravatar Nguyễn Thái Ngọc Duy1-31/+31
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-08apply: remove lego in i18n string in gitdiff_verify_nameLibravatar Nguyễn Thái Ngọc Duy1-4/+11
It marks the string "...inconsistent %s filename..." where %s is either "old" or "new" from caller. Make it two strings "...inconsistent new filename..." and "...inconsistent old filename...". Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-02Merge branch 'nd/i18n'Libravatar Junio C Hamano1-95/+111
More message strings marked for i18n. By Nguyễn Thái Ngọc Duy (10) and Jonathan Nieder (1) * nd/i18n: help: replace underlining "help -a" headers using hyphens with a blank line i18n: bundle: mark strings for translation i18n: index-pack: mark strings for translation i18n: apply: update say_patch_name to give translators complete sentence i18n: apply: mark strings for translation i18n: remote: mark strings for translation i18n: make warn_dangling_symref() automatically append \n i18n: help: mark strings for translation i18n: mark relative dates for translation strbuf: convenience format functions with \n automatically appended Makefile: feed all header files to xgettext
2012-04-24i18n: apply: update say_patch_name to give translators complete sentenceLibravatar Nguyễn Thái Ngọc Duy1-12/+20
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24i18n: apply: mark strings for translationLibravatar Nguyễn Thái Ngọc Duy1-83/+91
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-23Merge branch 'jh/apply-free-patch'Libravatar Junio C Hamano1-41/+133
Valgrind reports quite a lot of discarded memory inside apply. Fix them, audit and document the buffer ownership rules. By Junio C Hamano (8) and Jared Hance (1) * jh/apply-free-patch: apply: document buffer ownership rules across functions apply: tighten constness of line buffer apply: drop unused macro apply: free unused fragments for submodule patch apply: free patch->result apply: release memory for fn_table apply: free patch->{def,old,new}_name fields apply: rename free_patch() to free_patch_list() apply: do not leak patches and fragments
2012-04-11apply: document buffer ownership rules across functionsLibravatar Junio C Hamano1-2/+51
In general, the private functions in this file were not very much documented; even though what each of them do is reasonably self explanatory, the ownership rules for various buffers and data structures were not very obvious. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-11apply: tighten constness of line bufferLibravatar Junio C Hamano1-7/+7
These point into a single line in the patch text we read from the input, and they are not used to modify it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-11apply: drop unused macroLibravatar Junio C Hamano1-1/+0
CHUNKSIZE is no longer used. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-28apply: free unused fragments for submodule patchLibravatar Junio C Hamano1-9/+15
We simply discarded the fragments that we are not going to use upon seeing a patch to update the submodule commit bound at path that we have not checked out. Free these fragments, not to leak them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-27apply: free patch->resultLibravatar Junio C Hamano1-0/+1
This is by far the largest piece of data, much larger than the patch and fragment structures or the three name fields in the patch structure. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-27apply: release memory for fn_tableLibravatar Junio C Hamano1-1/+1
The fn_table is used to record the result of earlier patch application in case a hand-crafted input file contains multiple patches to the same file. Both its string key (filename) and the contents are borrowed from "struct patch" that represents the previous application in the same apply_patch() call, and they do not leak, but the table itself was not freed properly. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-27apply: free patch->{def,old,new}_name fieldsLibravatar Junio C Hamano1-26/+39
These were all allocated in the heap by parsing the header parts of the patch, but we did not bother to free them. Some used to share the memory (e.g. copying def_name to old_name) so this is not just the matter of adding three calls to free(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-27apply: rename free_patch() to free_patch_list()Libravatar Junio C Hamano1-14/+19
As that is the only logical name for a function that walks a list and frees each element on it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-07apply: do not leak patches and fragmentsLibravatar Jared Hance1-4/+23
In the while loop inside apply_patch, patch and fragments are dynamically allocated with a calloc. However, only unused patches are actually freed and the rest are left to leak. Since a list is actively built up consisting of the used patches, they can simply be iterated and freed at the end of the function. In addition, the text in fragments were not freed, primarily because they mostly point into a patch text that is freed as a whole. But there are some cases where new piece of memory is allocated and pointed by a fragment (namely, when handling a binary patch). Introduce a free_patch bitfield to mark each fragment if its text needs to be freed, and free patches, fragments and fragment text that need to be freed when we are done with the input. Signed-off-by: Jared Hance <jaredhance@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-03Use correct grammar in diffstat summary lineLibravatar Nguyễn Thái Ngọc Duy1-1/+2
"git diff --stat" and "git apply --stat" now learn to print the line "%d files changed, %d insertions(+), %d deletions(-)" in singular form whenever applicable. "0 insertions" and "0 deletions" are also omitted unless they are both zero. This matches how versions of "diffstat" that are not prehistoric produced their output, and also makes this line translatable. [jc: with help from Thomas Dickey in archaeology of "diffstat"] [jc: squashed Jonathan's updates to illustrations in tutorials and a test] Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-21Merge branch 'bc/maint-apply-check-no-patch' into maintLibravatar Junio C Hamano1-5/+5
* bc/maint-apply-check-no-patch: builtin/apply.c: report error on failure to recognize input t/t4131-apply-fake-ancestor.sh: fix broken test
2011-12-13Merge branch 'bc/maint-apply-check-no-patch'Libravatar Junio C Hamano1-5/+5
* bc/maint-apply-check-no-patch: builtin/apply.c: report error on failure to recognize input t/t4131-apply-fake-ancestor.sh: fix broken test
2011-12-13Merge branch 'maint-1.7.7' into maintLibravatar Junio C Hamano1-3/+0
* maint-1.7.7: Git 1.7.7.5 Git 1.7.6.5 blame: don't overflow time buffer fetch: create status table using strbuf checkout,merge: loosen overwriting untracked file check based on info/exclude cast variable in call to free() in builtin/diff.c and submodule.c apply: get rid of useless x < 0 comparison on a size_t type Conflicts: Documentation/git.txt GIT-VERSION-GEN RelNotes builtin/fetch.c
2011-12-13Merge branch 'ab/clang-lints' into maint-1.7.7Libravatar Junio C Hamano1-3/+0
* ab/clang-lints: cast variable in call to free() in builtin/diff.c and submodule.c apply: get rid of useless x < 0 comparison on a size_t type
2011-12-05Merge branch 'ab/clang-lints'Libravatar Junio C Hamano1-3/+0
* ab/clang-lints: cast variable in call to free() in builtin/diff.c and submodule.c apply: get rid of useless x < 0 comparison on a size_t type
2011-12-05builtin/apply.c: report error on failure to recognize inputLibravatar Brandon Casey1-5/+5
When git apply is passed something that is not a patch, it does not produce an error message or exit with a non-zero status if it was not actually "applying" the patch i.e. --check or --numstat etc were supplied on the command line. Fix this by producing an error when apply fails to find any hunks whatsoever while parsing the patch. This will cause some of the output formats (--numstat, --diffstat, etc) to produce an error when they formerly would have reported zero changes and exited successfully. That seems like the correct behavior though. Failure to recognize the input as a patch should be an error. Plus, add a test. Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-06apply: get rid of useless x < 0 comparison on a size_t typeLibravatar Ævar Arnfjörð Bjarmason1-3/+0
According to the C standard size_t is always unsigned, therefore the comparison "n1 < 0 || n2 < 0" when n1 and n2 are size_t will always be false. This was raised by clang 2.9 which throws this warning when compiling apply.c: builtin/apply.c:253:9: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (n1 < 0 || n2 < 0) ~~ ^ ~ builtin/apply.c:253:19: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (n1 < 0 || n2 < 0) ~~ ^ ~ This check was originally added in v1.6.5-rc0~53^2 by Giuseppe Bilotta while adding an option to git-apply to ignore whitespace differences. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21Merge branch 'jc/apply-blank-at-eof-fix' into maintLibravatar Junio C Hamano1-2/+9
* jc/apply-blank-at-eof-fix: apply --whitespace=error: correctly report new blank lines at end
2011-10-21Merge branch 'jm/maint-apply-detects-corrupt-patch-header' into maintLibravatar Junio C Hamano1-0/+3
* jm/maint-apply-detects-corrupt-patch-header: fix "git apply --index ..." not to deref NULL
2011-10-19Merge branch 'jm/maint-apply-detects-corrupt-patch-header'Libravatar Junio C Hamano1-0/+3
* jm/maint-apply-detects-corrupt-patch-header: fix "git apply --index ..." not to deref NULL
2011-10-13Merge branch 'jc/apply-blank-at-eof-fix'Libravatar Junio C Hamano1-2/+9
* jc/apply-blank-at-eof-fix: apply --whitespace=error: correctly report new blank lines at end
2011-10-12fix "git apply --index ..." not to deref NULLLibravatar Jim Meyering1-0/+3
I noticed this when "git am CORRUPTED" unexpectedly failed with an odd diagnostic, and even removed one of the files it was supposed to have patched. Reproduce with any valid old/new patch from which you have removed the "+++ b/FILE" line. You'll see a diagnostic like this fatal: unable to write file '(null)' mode 100644: Bad address and you'll find that FILE has been removed. The above is on glibc-based systems. On other systems, rather than getting "null", you may provoke a segfault as git tries to dereference the NULL file name. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-28apply: use OPT_NOOP_NOARGLibravatar René Scharfe1-7/+2
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-10zlib: zlib can only process 4GB at a timeLibravatar Junio C Hamano1-1/+1
The size of objects we read from the repository and data we try to put into the repository are represented in "unsigned long", so that on larger architectures we can handle objects that weigh more than 4GB. But the interface defined in zlib.h to communicate with inflate/deflate limits avail_in (how many bytes of input are we calling zlib with) and avail_out (how many bytes of output from zlib are we ready to accept) fields effectively to 4GB by defining their type to be uInt. In many places in our code, we allocate a large buffer (e.g. mmap'ing a large loose object file) and tell zlib its size by assigning the size to avail_in field of the stream, but that will truncate the high octets of the real size. The worst part of this story is that we often pass around z_stream (the state object used by zlib) to keep track of the number of used bytes in input/output buffer by inspecting these two fields, which practically limits our callchain to the same 4GB limit. Wrap z_stream in another structure git_zstream that can express avail_in and avail_out in unsigned long. For now, just die() when the caller gives a size that cannot be given to a single zlib call. In later patches in the series, we would make git_inflate() and git_deflate() internally loop to give callers an illusion that our "improved" version of zlib interface can operate on a buffer larger than 4GB in one go. Signed-off-by: Junio C Hamano <gitster@pobox.com>