summaryrefslogtreecommitdiff
path: root/builtin/apply.c
AgeCommit message (Collapse)AuthorFilesLines
2013-07-22Sync with Git 1.8.3.4Libravatar Junio C Hamano1-1/+1
2013-07-22Merge branch 'nd/const-struct-cache-entry'Libravatar Junio C Hamano1-6/+7
* nd/const-struct-cache-entry: Convert "struct cache_entry *" to "const ..." wherever possible
2013-07-22Merge branch 'tr/do-not-call-submodules-subprojects'Libravatar Junio C Hamano1-1/+1
* tr/do-not-call-submodules-subprojects: show-branch: fix description of --date-order apply, entry: speak of submodules instead of subprojects
2013-07-22update URL to the marc.info mail archiveLibravatar Ondřej Bílka1-1/+1
The name marc.theaimsgroup.com is no longer active, and has migrated to marc.info. Signed-off-by: Ondřej Bílka <neleai@seznam.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-19apply.c::find_name_traditional(): do not initialize len to the line's lengthLibravatar Stefan Beller1-1/+1
The variable len is set to len = strchrnul(line, '\n') - line; unconditionally 9 lines later, hence we can remove the call to strlen. Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-19Merge branch 'rs/logical-vs-binary-or' into maintLibravatar Junio C Hamano1-1/+1
* rs/logical-vs-binary-or: use logical OR (||) instead of binary OR (|) in logical context
2013-07-18apply, entry: speak of submodules instead of subprojectsLibravatar Thomas Rast1-1/+1
There are only four (with some generous rounding) instances in the current source code where we speak of "subproject" instead of "submodule". They are as follows: * one error message in git-apply and two in entry.c * the patch format for submodule changes The latter was introduced in 0478675 (Expose subprojects as special files to "git diff" machinery, 2007-04-15), apparently before the terminology was settled. We can of course not change the patch format. Let's at least change the error messages to consistently call them "submodule". Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15Merge branch 'tr/maint-apply-non-git-patch-parsefix' into maintLibravatar Junio C Hamano1-1/+1
"git apply" parsed patches that add new files, generated by programs other than Git, incorrectly. This is an old breakage in v1.7.11. * tr/maint-apply-non-git-patch-parsefix: apply: carefully strdup a possibly-NULL name
2013-07-09Convert "struct cache_entry *" to "const ..." wherever possibleLibravatar Nguyễn Thái Ngọc Duy1-6/+7
I attempted to make index_state->cache[] a "const struct cache_entry **" to find out how existing entries in index are modified and where. The question I have is what do we do if we really need to keep track of on-disk changes in the index. The result is - diff-lib.c: setting CE_UPTODATE - name-hash.c: setting CE_HASHED - preload-index.c, read-cache.c, unpack-trees.c and builtin/update-index: obvious - entry.c: write_entry() may refresh the checked out entry via fill_stat_cache_info(). This causes "non-const struct cache_entry *" in builtin/apply.c, builtin/checkout-index.c and builtin/checkout.c - builtin/ls-files.c: --with-tree changes stagemask and may set CE_UPDATE Of these, write_entry() and its call sites are probably most interesting because it modifies on-disk info. But this is stat info and can be retrieved via refresh, at least for porcelain commands. Other just uses ce_flags for local purposes. So, keeping track of "dirty" entries is just a matter of setting a flag in index modification functions exposed by read-cache.c. Except unpack-trees, the rest of the code base does not do anything funny behind read-cache's back. The actual patch is less valueable than the summary above. But if anyone wants to re-identify the above sites. Applying this patch, then this: diff --git a/cache.h b/cache.h index 430d021..1692891 100644 --- a/cache.h +++ b/cache.h @@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode) #define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1) struct index_state { - struct cache_entry **cache; + const struct cache_entry **cache; unsigned int version; unsigned int cache_nr, cache_alloc, cache_changed; struct string_list *resolve_undo; will help quickly identify them without bogus warnings. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26Merge branch 'tr/maint-apply-non-git-patch-parsefix'Libravatar Junio C Hamano1-1/+1
Fix for the codepath to parse patches that add new files, generated by programs other than Git. THis is an old breakage in v1.7.11 and will need to be merged down to the maintanance tracks. * tr/maint-apply-non-git-patch-parsefix: apply: carefully strdup a possibly-NULL name
2013-06-21apply: carefully strdup a possibly-NULL nameLibravatar Thomas Rast1-1/+1
2901bbe (apply: free patch->{def,old,new}_name fields, 2012-03-21) cleaned up the memory management of filenames in the patches, but forgot that find_name_traditional() can return NULL as a way of saying "I couldn't find a name". That NULL unfortunately gets passed into xstrdup() next, resulting in a segfault. Use null_strdup() so as to safely propagate the null, which will let us emit the correct error message. Reported-by: DevHC on #git Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-13use logical OR (||) instead of binary OR (|) in logical contextLibravatar René Scharfe1-1/+1
The compiler can short-circuit the evaluation of conditions strung together with logical OR operators instead of computing the resulting bitmask with binary ORs. More importantly, this patch makes the intent of the changed code clearer, because the logical context (as opposed to binary context) becomes immediately obvious. While we're at it, simplify the check for patch->is_rename in builtin/apply.c a bit; it can only be 0 or 1, so we don't need a comparison operator. Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-12Sync with 'maint'Libravatar Junio C Hamano1-3/+3
* maint: Correct common spelling mistakes in comments and tests kwset: fix spelling in comments precompose-utf8: fix spelling of "want" in error message compat/nedmalloc: fix spelling in comments compat/regex: fix spelling and grammar in comments obstack: fix spelling of similar contrib/subtree: fix spelling of accidentally git-remote-mediawiki: spelling fixes doc: various spelling fixes fast-export: fix argument name in error messages Documentation: distinguish between ref and offset deltas in pack-format i18n: make the translation of -u advice in one go
2013-04-12Correct common spelling mistakes in comments and testsLibravatar Stefano Lattarini1-3/+3
Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03Merge branch 'jc/apply-ws-fix-tab-in-indent'Libravatar Junio C Hamano1-6/+10
"git apply --whitespace=fix" was not prepared to see a line getting longer after fixing whitespaces (e.g. tab-in-indent aka Python). * jc/apply-ws-fix-tab-in-indent: test: resurrect q_to_tab apply --whitespace=fix: avoid running over the postimage buffer
2013-03-22apply --whitespace=fix: avoid running over the postimage bufferLibravatar Junio C Hamano1-6/+10
Originally update-pre-post-images could assume that any whitespace fixing will make the result only shorter by unexpanding runs of leading SPs into HTs and removing trailing whitespaces at the end of lines. Updating the post-image we read from the patch to match the actual result can be performed in-place under this assumption. These days, however, we have tab-in-indent (aka Python) rule whose result can be longer than the original, and we do need to allocate a larger buffer than the input and replace the result. Fortunately the support for lengthening rewrite was already added when we began supporting "match while ignoring whitespace differences" mode in 86c91f91794c (git apply: option to ignore whitespace differences, 2009-08-04). We only need to correctly count the number of bytes necessary to hold the updated result and tell the function to allocate a new buffer. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-14Merge branch 'jc/extended-fake-ancestor-for-gitlink'Libravatar Junio C Hamano1-2/+38
Instead of requiring the full 40-hex object names on the index line, we can read submodule commit object names from the textual diff when synthesizing a fake ancestore tree for "git am -3". * jc/extended-fake-ancestor-for-gitlink: apply: verify submodule commit object name better
2013-02-08Merge branch 'jk/apply-similaritly-parsing'Libravatar Junio C Hamano1-4/+6
Make sure the similarity value shown in the "apply --summary" output is sensible, even when the input had a bogus value. * jk/apply-similaritly-parsing: builtin/apply: tighten (dis)similarity index parsing
2013-02-05Merge branch 'jc/fake-ancestor-with-non-blobs'Libravatar Junio C Hamano1-14/+16
Rebasing the history of superproject with change in the submodule was broken since v1.7.12. * jc/fake-ancestor-with-non-blobs: apply: diagnose incomplete submodule object name better apply: simplify build_fake_ancestor() git-am: record full index line in the patch used while rebasing
2013-02-05apply: verify submodule commit object name betterLibravatar Junio C Hamano1-2/+38
A textual patch also records the submodule commit object name in full. Make the parsing more robust by reading from there and verifying the (possibly abbreviated) name on the index line matches. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-03builtin/apply: tighten (dis)similarity index parsingLibravatar John Keeping1-4/+6
This was prompted by an incorrect warning issued by clang [1], and a suggestion by Linus to restrict the range to check for values greater than INT_MAX since these will give bogus output after casting to int. In fact the (dis)similarity index is a percentage, so reject values greater than 100. [1] http://article.gmane.org/gmane.comp.version-control.git/213857 Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-31apply: diagnose incomplete submodule object name betterLibravatar Junio C Hamano1-1/+5
"git am -3" uses this function to build a tree that records how the preimage the patch was created from would have looked like. An abbreviated object name on the index line is ordinarily sufficient for us to figure out the object name the preimage tree would have contained, but a change to a submodule by definition shows an object name of a submodule commit which our repository should not have, and get_sha1_blob() is not an appropriate way to read it (or get_sha1() for that matter). Use get_sha1_hex() and complain if we do not find a full object name there. We could read from the payload part of the patch to learn the full object name of the commit, but the primary user "git rebase" has been fixed to give us a full object name, so this should suffice for now. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-31apply: simplify build_fake_ancestor()Libravatar Junio C Hamano1-14/+12
The local variable sha1_ptr in the build_fake_ancestor() function used to either point at the null_sha1[] (if the ancestor did not have the path) or at sha1[] (if we read the object name into the local array), but 7a98869 (apply: get rid of --index-info in favor of --build-fake-ancestor, 2007-09-17) made the "missing in the ancestor" case unnecessary, hence sha1_ptr, when used, always points at the local array. Get rid of the unneeded variable, and restructure the if/else cascade a bit to make it easier to read. There should be no behaviour change. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-06Merge branch 'jc/apply-trailing-blank-removal'Libravatar Junio C Hamano1-6/+17
Fix to update_pre_post_images() that did not take into account the possibility that whitespace fix could shrink the preimage and change the number of lines in it. * jc/apply-trailing-blank-removal: apply.c:update_pre_post_images(): the preimage can be truncated
2012-10-12apply.c:update_pre_post_images(): the preimage can be truncatedLibravatar Junio C Hamano1-6/+17
5166714 (apply: Allow blank context lines to match beyond EOF, 2010-03-06) and then later 0c3ef98 (apply: Allow blank *trailing* context lines to match beyond EOF, 2010-04-08) taught "git apply" to trim new blank lines at the end in the patch text when matching the contents being patched and the preimage recorded in the patch, under --whitespace=fix mode. When a preimage is modified to match the current contents in preparation for such a "fixed" patch application, the context lines in the postimage must be updated to match (otherwise, it would reintroduce whitespace breakages), and update_pre_post_images() function is responsible for doing this. However, this function was not updated to take into account a case where the removal of trailing blank lines reduces the number of lines in the preimage, and triggered an assertion error. The logic to fix the postimage by copying the corrected context lines from the preimage was not prepared to handle this case, either, but it was protected by the assert() and only got exposed when the assertion is corrected. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-12Merge branch 'maint-1.7.11' into maintLibravatar Junio C Hamano1-25/+43
2012-09-12Merge branch 'jc/apply-binary-p0' into maint-1.7.11Libravatar Junio C Hamano1-25/+43
"git apply -p0" did not parse pathnames on "diff --git" line correctly. This caused patches that had pathnames in no other places to be mistakenly rejected (most notably, binary patch that does not rename nor change mode). Textual patches, renames or mode changes have preimage and postimage pathnames in different places in a form that can be parsed unambiguously and did not suffer from this problem. * jc/apply-binary-p0: apply: compute patch->def_name correctly under -p0
2012-09-11Sync with 1.7.11.6Libravatar Junio C Hamano1-1/+0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-11Merge branch 'pg/maint-apply-remove-unused-variable' into maint-1.7.11Libravatar Junio C Hamano1-1/+0
* pg/maint-apply-remove-unused-variable: apply: delete unused deflate_origlen from patch struct
2012-09-07Merge branch 'jc/apply-binary-p0'Libravatar Junio C Hamano1-25/+43
"git apply -p0" did not parse pathnames on "diff --git" line correctly. This caused patches that had pathnames in no other places to be mistakenly rejected (most notably, binary patch that does not rename nor change mode). Textual patches, renames or mode changes have preimage and postimage pathnames in different places in a form that can be parsed unambiguously and did not suffer from this problem. * jc/apply-binary-p0: apply: compute patch->def_name correctly under -p0
2012-09-07Merge branch 'nd/i18n-parseopt-help'Libravatar Junio C Hamano1-1/+1
A lot of i18n mark-up for the help text from "git <cmd> -h". * nd/i18n-parseopt-help: (66 commits) Use imperative form in help usage to describe an action Reduce translations by using same terminologies i18n: write-tree: mark parseopt strings for translation i18n: verify-tag: mark parseopt strings for translation i18n: verify-pack: mark parseopt strings for translation i18n: update-server-info: mark parseopt strings for translation i18n: update-ref: mark parseopt strings for translation i18n: update-index: mark parseopt strings for translation i18n: tag: mark parseopt strings for translation i18n: symbolic-ref: mark parseopt strings for translation i18n: show-ref: mark parseopt strings for translation i18n: show-branch: mark parseopt strings for translation i18n: shortlog: mark parseopt strings for translation i18n: rm: mark parseopt strings for translation i18n: revert, cherry-pick: mark parseopt strings for translation i18n: rev-parse: mark parseopt strings for translation i18n: reset: mark parseopt strings for translation i18n: rerere: mark parseopt strings for translation i18n: status: mark parseopt strings for translation i18n: replace: mark parseopt strings for translation ...
2012-08-24apply: compute patch->def_name correctly under -p0Libravatar Junio C Hamano1-25/+43
Back when "git apply" was written, we made sure that the user can skip more than the default number of path components (i.e. 1) by giving "-p<n>", but the logic for doing so was built around the notion of "we skip N slashes and stop". This obviously does not work well when running under -p0 where we do not want to skip any, but still want to skip SP/HT that separates the pathnames of preimage and postimage and want to reject absolute pathnames. Stop using "stop_at_slash()", and instead introduce a new helper "skip_tree_prefix()" with similar logic but works correctly even for the -p0 case. This is an ancient bug, but has been masked for a long time because most of the patches are text and have other clues to tell us the name of the preimage and the postimage. Noticed by Colin McCabe. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-22Use imperative form in help usage to describe an actionLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-22Merge branch 'pg/maint-apply-remove-unused-variable'Libravatar Junio C Hamano1-1/+0
Remove an unused field. * pg/maint-apply-remove-unused-variable: apply: delete unused deflate_origlen from patch struct
2012-08-05apply: delete unused deflate_origlen from patch structLibravatar Paul Gortmaker1-1/+0
It hasn't been used since 2006, as of commit 3cd4f5e8 "git-apply --binary: clean up and prepare for --reverse" Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-23Merge branch 'tg/ce-namelen-field'Libravatar Junio C Hamano1-2/+4
Split lower bits of ce_flags field and creates a new ce_namelen field in the in-core index structure. * tg/ce-namelen-field: Strip namelen out of ce_flags into a ce_namelen field
2012-07-22Merge branch 'jc/sha1-name-more'Libravatar Junio C Hamano1-1/+1
Teaches the object name parser things like a "git describe" output is always a commit object, "A" in "git log A" must be a committish, and "A" and "B" in "git log A...B" both must be committish, etc., to prolong the lifetime of abbreviated object names. * jc/sha1-name-more: (27 commits) t1512: match the "other" object names t1512: ignore whitespaces in wc -l output rev-parse --disambiguate=<prefix> rev-parse: A and B in "rev-parse A..B" refer to committish reset: the command takes committish commit-tree: the command wants a tree and commits apply: --build-fake-ancestor expects blobs sha1_name.c: add support for disambiguating other types revision.c: the "log" family, except for "show", takes committish revision.c: allow handle_revision_arg() to take other flags sha1_name.c: introduce get_sha1_committish() sha1_name.c: teach lookup context to get_sha1_with_context() sha1_name.c: many short names can only be committish sha1_name.c: get_sha1_1() takes lookup flags sha1_name.c: get_describe_name() by definition groks only commits sha1_name.c: teach get_short_sha1() a commit-only option sha1_name.c: allow get_short_sha1() to take other flags get_sha1(): fix error status regression sha1_name.c: restructure disambiguation of short names sha1_name.c: correct misnamed "canonical" and "res" ...
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-11Strip namelen out of ce_flags into a ce_namelen fieldLibravatar Thomas Gummerer1-1/+2
Strip the name length from the ce_flags field and move it into its own ce_namelen field in struct cache_entry. This will both give us a tiny bit of a performance enhancement when working with long pathnames and is a refactoring for more readability of the code. It enhances readability, by making it more clear what is a flag, and where the length is stored and make it clear which functions use stages in comparisions and which only use the length. It also makes CE_NAMEMASK private, so that users don't mistakenly write the name length in the flags. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-09apply: --build-fake-ancestor expects blobsLibravatar Junio C Hamano1-1/+1
The "index" line read from the patch to reconstruct a partial preimage tree records the object names of blob objects. Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>