summaryrefslogtreecommitdiff
path: root/builtin/apply.c
AgeCommit message (Collapse)AuthorFilesLines
2017-10-06apply: move lockfile into `apply_state`Libravatar Martin Ågren1-3/+1
We have two users of `struct apply_state` and the related functionality in apply.c. Each user sets up its `apply_state` by handing over a pointer to its static `lock_file`. (Before 076aa2cbd (tempfile: auto-allocate tempfiles on heap, 2017-09-05), we could never free lockfiles, so making them static was a reasonable approach.) Other than that, they never directly access their `lock_file`s, which are instead handled by the functionality in apply.c. To make life easier for the caller and to make it less tempting for a future caller to mess with the lock, make apply.c fully responsible for setting up the `lock_file`. As mentioned above, it is now safe to free a `lock_file`, so we can make the `struct apply_state` contain an actual `struct lock_file` instead of a pointer to one. The user in builtin/apply.c is rather simple. For builtin/am.c, we might worry that the lock state is actually meant to be inherited across calls. But the lock is only taken as `apply_all_patches()` executes, and code inspection shows that it will always be released. Alternatively, we can observe that the lock itself is never queried directly. When we decide whether we should lock, we check a related variable `newfd`. That variable is not inherited, so from the point of view of apply.c, the state machine really is reset with each call to `init_apply_state()`. (It would be a bug if `newfd` and the lock status were not in sync. The duplication of information in `newfd` and the lock will be addressed in the next patch.) Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07apply: refactor `git apply` option parsingLibravatar Christian Couder1-71/+3
Parsing `git apply` options can be useful to other commands that want to call the libified apply functionality, because this way they can easily pass some options from their own command line to the libified apply functionality. This will be used by `git am` in a following patch. To make this possible, let's refactor the `git apply` option parsing code into a new libified apply_parse_options() function. Doing that makes it possible to remove some functions definitions from "apply.h" and make them static in "apply.c". Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07apply: make it possible to silently applyLibravatar Christian Couder1-1/+1
This changes 'int apply_verbosely' into 'enum apply_verbosity', and changes the possible values of the variable from a bool to a tristate. The previous 'false' state is changed into 'verbosity_normal'. The previous 'true' state is changed into 'verbosity_verbose'. The new added state is 'verbosity_silent'. It should prevent anything to be printed on both stderr and stdout. This is needed because `git am` wants to first call apply functionality silently, if it can then fall back on 3-way merge in case of error. Printing on stdout, and calls to warning() or error() are not taken care of in this patch, as that will be done in following patches. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07apply: move libified code from builtin/apply.c to apply.{c,h}Libravatar Christian Couder1-4732/+1
As most of the apply code in builtin/apply.c has been libified by a number of previous commits, it can now be moved to apply.{c,h}, so that more code can use it. Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07apply: rename and move opt constants to apply.hLibravatar Christian Couder1-7/+4
The constants for the "inaccurate-eof" and the "recount" options will be used in both "apply.c" and "builtin/apply.c", so they need to go into "apply.h", and therefore they need a name that is more specific to the API they belong to. Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07builtin/apply: rename option parsing functionsLibravatar Christian Couder1-20/+20
As these functions are going to be part of the libified apply API, let's give them a name that is more specific to the apply API. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07builtin/apply: make create_one_file() return -1 on errorLibravatar Christian Couder1-15/+21
To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", create_one_file() should return -1 instead of calling exit(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07builtin/apply: make try_create_file() return -1 on errorLibravatar Christian Couder1-11/+33
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", try_create_file() should return -1 in case of error. Unfortunately try_create_file() currently returns -1 to signal a recoverable error. To fix that, let's make it return 1 in case of a recoverable error and -1 in case of an unrecoverable error. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make write_out_results() return -1 on errorLibravatar Christian Couder1-6/+21
To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", write_out_results() should return -1 instead of calling exit(). Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make write_out_one_result() return -1 on errorLibravatar Christian Couder1-22/+16
To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", write_out_one_result() should just return what remove_file() and create_file() are returning instead of calling exit(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make create_file() return -1 on errorLibravatar Christian Couder1-12/+13
To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", create_file() should just return what add_conflicted_stages_file() and add_index_file() are returning instead of calling exit(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make add_index_file() return -1 on errorLibravatar Christian Couder1-17/+31
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", add_index_file() should return -1 instead of calling die(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make add_conflicted_stages_file() return -1 on errorLibravatar Christian Couder1-7/+13
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", add_conflicted_stages_file() should return -1 instead of calling die(). Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make remove_file() return -1 on errorLibravatar Christian Couder1-6/+11
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", remove_file() should return -1 instead of calling die(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make build_fake_ancestor() return -1 on errorLibravatar Christian Couder1-15/+26
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", build_fake_ancestor() should return -1 instead of calling die(). Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: change die_on_unsafe_path() to check_unsafe_path()Libravatar Christian Couder1-11/+21
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", die_on_unsafe_path() should return a negative integer instead of calling die(), so while doing that let's change its name to check_unsafe_path(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make gitdiff_*() return -1 on errorLibravatar Christian Couder1-19/+21
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", gitdiff_*() functions should return -1 instead of calling die(). A previous patch made it possible for gitdiff_*() functions to return -1 in case of error. Let's take advantage of that to make gitdiff_verify_name() return -1 on error, and to have gitdiff_oldname() and gitdiff_newname() directly return what gitdiff_verify_name() returns. Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make gitdiff_*() return 1 at end of headerLibravatar Christian Couder1-3/+9
The gitdiff_*() functions that are called as p->fn() in parse_git_header() should return 1 instead of -1 in case of end of header or unrecognized input, as these are not real errors. It just instructs the parser to break out. This makes it possible for gitdiff_*() functions to return -1 in case of a real error. This will be done in a following patch. Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make parse_traditional_patch() return -1 on errorLibravatar Christian Couder1-6/+9
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", parse_traditional_patch() should return -1 instead of calling die(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make apply_all_patches() return 128 or 1 on errorLibravatar Christian Couder1-11/+26
To finish libifying the apply functionality, apply_all_patches() should not die() or exit() in case of error, but return either 128 or 1, so that it gives the same exit code as when die() or exit(1) is called. This way scripts relying on the exit code don't need to be changed. While doing that we must take care that file descriptors are properly closed and, if needed, reset to a sensible value. Also, according to the lockfile API, when finished with a lockfile, one should either commit it or roll it back. This is even more important now that the same lockfile can be passed to init_apply_state() many times to be reused by series of calls to the apply lib functions. Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: move check_apply_state() to apply.cLibravatar Christian Couder1-32/+0
To libify `git apply` functionality we must make check_apply_state() usable outside "builtin/apply.c". Let's do that by moving it into "apply.c". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make check_apply_state() return -1 instead of die()ingLibravatar Christian Couder1-8/+11
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", check_apply_state() should return -1 instead of calling die(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11apply: make init_apply_state() return -1 instead of exit()ingLibravatar Christian Couder1-1/+2
To libify `git apply` functionality we have to signal errors to the caller instead of exit()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", init_apply_state() should return -1 instead of calling exit(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: move init_apply_state() to apply.cLibravatar Christian Couder1-91/+0
To libify `git apply` functionality we must make init_apply_state() usable outside "builtin/apply.c". Let's do that by moving it into a new "apply.c". Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make parse_ignorewhitespace_option() return -1 instead of ↵Libravatar Christian Couder1-7/+7
die()ing To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", parse_ignorewhitespace_option() should return -1 instead of calling die(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make parse_whitespace_option() return -1 instead of die()ingLibravatar Christian Couder1-11/+12
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, parse_whitespace_option() should return -1 instead of calling die(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make parse_single_patch() return -1 on errorLibravatar Christian Couder1-4/+13
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, parse_single_patch() should return a negative integer instead of calling die(). Let's do that by using error() and let's adjust the related test cases accordingly. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make parse_chunk() return a negative integer on errorLibravatar Christian Couder1-8/+14
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing or exit()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, parse_chunk() should return a negative integer instead of calling die() or exit(). As parse_chunk() is called only by apply_patch() which already returns either -1 or -128 when an error happened, let's make it also return -1 or -128. This makes it compatible with what find_header() and parse_binary() already return. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make find_header() return -128 instead of die()ingLibravatar Christian Couder1-12/+28
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, let's make find_header() return -128 instead of calling die(). We could make it return -1, unfortunately find_header() already returns -1 when no header is found. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: read_patch_file() return -1 instead of die()ingLibravatar Christian Couder1-3/+5
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. Let's do that by returning -1 instead of die()ing in read_patch_file(). Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: make apply_patch() return -1 or -128 instead of die()ingLibravatar Christian Couder1-15/+45
To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. As a first step in this direction, let's make apply_patch() return -1 or -128 in case of errors instead of dying. For now its only caller apply_all_patches() will exit(128) when apply_patch() return -128 and it will exit(1) when it returns -1. We exit() with code 128 because that was what die() was doing and we want to keep the distinction between exiting with code 1 and exiting with code 128. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11apply: move 'struct apply_state' to apply.hLibravatar Christian Couder1-97/+1
To libify `git apply` functionality we must make 'struct apply_state' usable outside "builtin/apply.c". Let's do that by creating a new "apply.h" and moving 'struct apply_state' there. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11apply: make some names more specificLibravatar Christian Couder1-10/+10
To prepare for some structs and constants being moved from builtin/apply.c to apply.h, we should give them some more specific names to avoid possible name collisions in the global namespace. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13Merge branch 'va/i18n-even-more'Libravatar Junio C Hamano1-3/+3
More markings of messages for i18n, with updates to various tests to pass GETTEXT_POISON tests. One patch from the original submission dropped due to conflicts with jk/upload-pack-hook, which is still in flux. * va/i18n-even-more: (38 commits) t5541: become resilient to GETTEXT_POISON i18n: branch: mark comment when editing branch description for translation i18n: unmark die messages for translation i18n: submodule: escape shell variables inside eval_gettext i18n: submodule: join strings marked for translation i18n: init-db: join message pieces i18n: remote: allow translations to reorder message i18n: remote: mark URL fallback text for translation i18n: standardise messages i18n: sequencer: add period to error message i18n: merge: change command option help to lowercase i18n: merge: mark messages for translation i18n: notes: mark options for translation i18n: notes: mark strings for translation i18n: transport-helper.c: change N_() call to _() i18n: bisect: mark strings for translation t5523: use test_i18ngrep for negation t4153: fix negated test_i18ngrep call t9003: become resilient to GETTEXT_POISON tests: unpack-trees: update to use test_i18n* functions ...
2016-07-06Merge branch 'jk/string-list-static-init'Libravatar Junio C Hamano1-0/+3
Instead of taking advantage of a struct string_list that is allocated with all NULs happens to be STRING_LIST_INIT_NODUP kind, initialize them explicitly as such, to document their behaviour better. * jk/string-list-static-init: use string_list initializer consistently blame,shortlog: don't make local option variables static interpret-trailers: don't duplicate option strings parse_opt_string_list: stop allocating new strings
2016-06-27Merge branch 'cc/apply-introduce-state'Libravatar Junio C Hamano1-609/+820
The "git apply" standalone program is being libified; this is the first step to move many state variables into a structure that can be explicitly (re)initialized to make the machinery callable more than once. The next step that moves some remaining state variables into the structure and turns die()s into an error return that propagates up to the caller is not queued yet but in flight. It would be good to review the above first and give the remainder of the series a solid base to build on. * cc/apply-introduce-state: (50 commits) builtin/apply: remove misleading comment on lock_file field builtin/apply: move 'newfd' global into 'struct apply_state' builtin/apply: add 'lock_file' pointer into 'struct apply_state' builtin/apply: move applying patches into apply_all_patches() builtin/apply: move 'state' check into check_apply_state() builtin/apply: move 'symlink_changes' global into 'struct apply_state' builtin/apply: move 'fn_table' global into 'struct apply_state' builtin/apply: move 'state_linenr' global into 'struct apply_state' builtin/apply: move 'max_change' and 'max_len' into 'struct apply_state' builtin/apply: move 'ws_ignore_action' into 'struct apply_state' builtin/apply: move 'ws_error_action' into 'struct apply_state' builtin/apply: move 'applied_after_fixing_ws' into 'struct apply_state' builtin/apply: move 'squelch_whitespace_errors' into 'struct apply_state' builtin/apply: remove whitespace_option arg from set_default_whitespace_mode() builtin/apply: move 'whitespace_option' into 'struct apply_state' builtin/apply: move 'whitespace_error' global into 'struct apply_state' builtin/apply: move 'root' global into 'struct apply_state' builtin/apply: move 'p_value_known' global into 'struct apply_state' builtin/apply: move 'p_value' global into 'struct apply_state' builtin/apply: move 'has_include' global into 'struct apply_state' ...
2016-06-17i18n: standardise messagesLibravatar Vasco Almeida1-3/+3
Standardise messages in order to save translators some work. Nuances fixed in this commit: "failed to read %s" "read of %s failed" "detach the HEAD at named commit" "detach HEAD at named commit" "removing '%s' failed" "failed to remove '%s'" "index file corrupt" "corrupt index file" "failed to read %s" "read of %s failed" "detach the HEAD at named commit" "detach HEAD at named commit" Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-13use string_list initializer consistentlyLibravatar Jeff King1-3/+3
There are two types of string_lists: those that own the string memory, and those that don't. You can tell the difference by the strdup_strings flag, and one should use either STRING_LIST_INIT_DUP, or STRING_LIST_INIT_NODUP as an initializer. Historically, the normal all-zeros initialization has corresponded to the NODUP case. Many sites use no initializer at all, and that works as a shorthand for that case. But for a reader of the code, it can be hard to remember which is which. Let's be more explicit and actually have each site declare which type it means to use. This is a fairly mechanical conversion; I assumed each site was correct as-is, and just switched them all to NODUP. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06builtin/apply: remove misleading comment on lock_file fieldLibravatar Junio C Hamano1-4/+1
Just like pointer field like prefix, the piece of memory pointed at by lock_file field is not owned by the apply_state structure. It is true that the caller needs to be careful about the lifetime rule for lockfile instances, but that is none of this API's business. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-03Merge branch 'rs/apply-name-terminate'Libravatar Junio C Hamano1-2/+2
Code clean-up. * rs/apply-name-terminate: apply: remove unused parameters from name_terminate()
2016-06-03builtin/apply: move 'newfd' global into 'struct apply_state'Libravatar Christian Couder1-4/+5
To libify the apply functionality the 'newfd' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-03builtin/apply: add 'lock_file' pointer into 'struct apply_state'Libravatar Christian Couder1-4/+15
We cannot have a 'struct lock_file' allocated on the stack, as lockfile.c keeps a linked list of all created lock_file structures. Also 'struct apply_state' users might later want the same 'struct lock_file' instance to be reused by different series of calls to the apply api. So let's add a 'struct lock_file *lock_file' pointer into 'struct apply_state' and have the user of 'struct apply_state' allocate memory for the actual 'struct lock_file' instance. Let's also add an argument to init_apply_state(), so that the caller can easily supply a pointer to the allocated instance. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move applying patches into apply_all_patches()Libravatar Christian Couder1-58/+71
To libify the apply functionality we should provide a function to apply many patches. Let's move the code to do that into a new apply_all_patches() function. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'state' check into check_apply_state()Libravatar Christian Couder1-23/+29
To libify the apply functionality we should provide a function to check that the values in a 'struct apply_state' instance are coherent. Let's move the code to do that into a new check_apply_state() function. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'symlink_changes' global into 'struct apply_state'Libravatar Christian Couder1-22/+28
To libify the apply functionality the 'symlink_changes' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'fn_table' global into 'struct apply_state'Libravatar Christian Couder1-22/+25
To libify the apply functionality the 'fn_table' variable should not be static and global to the file. Let's move it into 'struct apply_state'. As fn_table is cleared at the end of apply_patch(), it is not necessary to clear it in clear_apply_state(). Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'state_linenr' global into 'struct apply_state'Libravatar Christian Couder1-35/+36
To libify the apply functionality the 'state_linenr' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'max_change' and 'max_len' into 'struct apply_state'Libravatar Christian Couder1-24/+25
To libify the apply functionality the 'max_change' and 'max_len' variables should not be static and global to the file. Let's move them into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'ws_ignore_action' into 'struct apply_state'Libravatar Christian Couder1-17/+20
To libify the apply functionality the 'ws_ignore_action' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'ws_error_action' into 'struct apply_state'Libravatar Christian Couder1-28/+33
To libify the apply functionality the 'ws_error_action' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>