summaryrefslogtreecommitdiff
path: root/add-patch.c
Commit message (Collapse)AuthorAgeFilesLines
* editor: move editor-related functions and declarations into common fileElijah Newren2023-04-111-0/+1
| | | | | | | | | cache.h and strbuf.[ch] had editor-related functions. Move these into editor.[ch]. Signed-off-by: Elijah Newren <newren@gmail.com> Acked-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* object-name.h: move declarations for object-name.c functions from cache.hElijah Newren2023-04-111-0/+1
| | | | | | Signed-off-by: Elijah Newren <newren@gmail.com> Acked-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* treewide: be explicit about dependence on advice.hElijah Newren2023-04-111-0/+1
| | | | | | | | | | | Dozens of files made use of advice functions, without explicitly including advice.h. This made it more difficult to find which files could remove a dependence on cache.h. Make C files explicitly include advice.h if they are using it. Signed-off-by: Elijah Newren <newren@gmail.com> Acked-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ab/remove-implicit-use-of-the-repository' into ↵Junio C Hamano2023-04-041-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | en/header-split-cache-h * ab/remove-implicit-use-of-the-repository: libs: use "struct repository *" argument, not "the_repository" post-cocci: adjust comments for recent repo_* migration cocci: apply the "revision.h" part of "the_repository.pending" cocci: apply the "rerere.h" part of "the_repository.pending" cocci: apply the "refs.h" part of "the_repository.pending" cocci: apply the "promisor-remote.h" part of "the_repository.pending" cocci: apply the "packfile.h" part of "the_repository.pending" cocci: apply the "pretty.h" part of "the_repository.pending" cocci: apply the "object-store.h" part of "the_repository.pending" cocci: apply the "diff.h" part of "the_repository.pending" cocci: apply the "commit.h" part of "the_repository.pending" cocci: apply the "commit-reach.h" part of "the_repository.pending" cocci: apply the "cache.h" part of "the_repository.pending" cocci: add missing "the_repository" macros to "pending" cocci: sort "the_repository" rules by header cocci: fix incorrect & verbose "the_repository" rules cocci: remove dead rule from "the_repository.pending.cocci"
| * cocci: apply the "cache.h" part of "the_repository.pending"Ævar Arnfjörð Bjarmason2023-03-281-1/+1
| | | | | | | | | | | | | | | | Apply the part of "the_repository.pending.cocci" pertaining to "cache.h". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | environment: move comment_line_char from cache.hElijah Newren2023-03-211-0/+1
| | | | | | | | | | | | | | | | This is one step towards making strbuf.c not depend upon cache.h. Additional steps will follow in subsequent commits. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | treewide: be explicit about dependence on gettext.hElijah Newren2023-03-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Dozens of files made use of gettext functions, without explicitly including gettext.h. This made it more difficult to find which files could remove a dependence on cache.h. Make C files explicitly include gettext.h if they are using it. However, while compat/fsmonitor/fsm-ipc-darwin.c should also gain an include of gettext.h, it was left out to avoid conflicting with an in-flight topic. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/add-p-unmerged-fix'Junio C Hamano2023-03-191-1/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | "git add -p" while the index is unmerged sometimes failed to parse the diff output it internally produces and died, which has been corrected. * jk/add-p-unmerged-fix: add-patch: handle "* Unmerged path" lines
| * | add-patch: handle "* Unmerged path" linesJeff King2023-03-091-1/+2
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we generate a diff with --cached, unmerged entries have no oid for their index entry: $ git diff-index --abbrev --cached HEAD :100644 000000 f719efd 0000000 U my-conflict So when we are asked to produce a patch, since we only have one side, we just emit a special message: $ git diff-index --cached -p HEAD * Unmerged path my-conflict This confuses interactive-patch modes that look at cached diffs. For example: $ git reset -p BUG: add-patch.c:498: diff starts with unexpected line: * Unmerged path my-conflict Making things even more confusing, you'll get that error only if the unmerged entry is alphabetically the first changed file. Otherwise, we simply stick the unrecognized line to the end of the previous hunk. There it's mostly harmless, as it eventually gets fed back to "git apply", which happily ignores it. But it's still shown to the user attached to the hunk, which is wrong. So let's handle these lines as a noop. There's not really anything useful to do with a conflicted merge in this case, and that's what we do for other cases like "add -p". There we get a "diff --cc" line, which we accept as starting a new file, but we refuse to use any of its hunks (their headers start with "@@@" and not "@@ ", so we silently ignore them). It seems like simply recognizing the line and continuing in our parsing loop would work. But we actually need to run the rest of the loop body to handle matching up our colored/filtered output. But that code assumes that we have some active file_diff we're working on. So instead, we'll just insert a dummy entry into our array. This ends up the same as if we saw a "diff --cc" line (a file with no hunks). Reported-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | alloc.h: move ALLOC_GROW() functions from cache.hElijah Newren2023-02-231-0/+1
|/ | | | | | | | | This allows us to replace includes of cache.h with includes of the much smaller alloc.h in many places. It does mean that we also need to add includes of alloc.h in a number of C files. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* read-cache API & users: make discard_index() return voidÆvar Arnfjörð Bjarmason2022-11-211-1/+2
| | | | | | | | | | The discard_index() function has not returned non-zero since 7a51ed66f65 (Make on-disk index representation separate from in-core one, 2008-01-14), but we've had various code in-tree still acting as though that might be the case. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'rs/add-p-worktree-mode-prompt-fix'Junio C Hamano2022-09-151-8/+8
|\ | | | | | | | | | | | | Fix another UI regression in the reimplemented "add -p". * rs/add-p-worktree-mode-prompt-fix: add -p: fix worktree patch mode prompts
| * add -p: fix worktree patch mode promptsRené Scharfe2022-09-141-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cee6cb7300 (built-in add -p: implement the "worktree" patch modes, 2019-12-21) added the worktree patch modes to the built-in add -p. Its commit message claims to be a port of 2f0896ec3ad4 (restore: support --patch, 2019-04-25), which did the same for the script git-add--interactive.perl. The script mentioned only the worktree in its prompt messages in worktree mode, while the built-in mentions the worktree and also the index, even though the command doesn't actually affect the index. 2c8bd8471a (checkout -p: handle new files correctly, 2020-05-27) added new prompt messages for addition that also mention the index in worktree mode in the built-in, but not in the script. Correct these prompts to state that only the worktree will be affected. Reported-by: David Plumpton <david.plumpton@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'js/builtin-add-p-portability-fix'Junio C Hamano2022-09-131-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | More fixes to "add -p" * js/builtin-add-p-portability-fix: t6132(NO_PERL): do not run the scripted `add -p` t3701: test the built-in `add -i` regardless of NO_PERL add -p: avoid ambiguous signed/unsigned comparison
| * | add -p: avoid ambiguous signed/unsigned comparisonJohannes Schindelin2022-08-301-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the interactive `add` operation, users can choose to jump to specific hunks, and Git will present the hunk list in that case. To avoid showing too many lines at once, only a maximum of 21 hunks are shown, skipping the "mode change" pseudo hunk. The comparison performed to skip the "mode change" pseudo hunk (if any) compares a signed integer `i` to the unsigned value `mode_change` (which can be 0 or 1 because it is a 1-bit type). According to section 6.3.1.8 of the C99 standard (see e.g. https://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf), what should happen is an automatic conversion of the "lesser" type to the "greater" type, but since the types differ in signedness, it is ill-defined what is the correct "usual arithmetic conversion". Which means that Visual C's behavior can (and does) differ from GCC's: When compiling Git using the latter, `add -p`'s `goto` command shows no hunks by default because it casts a negative start offset to a pretty large unsigned value, breaking the "goto hunk" test case in `t3701-add-interactive.sh`. Let's avoid that by converting the unsigned bit explicitly to a signed integer. Note: This is a long-standing bug in the Visual C build of Git, but it has never been caught because t3701 is skipped when `NO_PERL` is set, which is the case in the `vs-test` jobs of Git's CI runs. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | add -p: ignore dirty submodulesJohannes Schindelin2022-09-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Thanks to always running `diff-index` and `diff-files` with the `--numstat` option (the latter with `--ignore-submodules=dirty`) before even generating any real diff to parse, the Perl version of `git add -p` simply ignored dirty submodules and does not even offer them up for staging. However, the built-in variant did not use that flag because it tries to run only one `diff` command, skipping the unneeded `diff-index`/`diff-files` invocation of the Perl variant and therefore only faithfully recapitulates what the Perl code does once it _does_ generate and parse the real diff. This causes a problem when running the built-in `add -p` with `diff-so-fancy` because that diff colorizer always inserts an empty line before the diff header to ensure that it produces 4 lines as expected by `git add -p` (the equivalent of the non-colorized `diff`, `index`, `---` and `+++` lines). But `git diff-files` does not produce any `index` line for dirty submodules. The underlying problem is not even the discrepancy in lines, but that `git add -p` presents diffs for dirty submodules: there is nothing that _can_ be staged for those. Let's fix that bug, and teach the built-in `add -p` to ignore dirty submodules, too. This _incidentally_ also fixes the `diff-so-fancy` problem ;-) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | add -p: gracefully handle unparseable hunk headers in colored diffsJohannes Schindelin2022-09-011-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In https://lore.kernel.org/git/ecf6f5be-22ca-299f-a8f1-bda38e5ca246@gmail.com, Phillipe Blain reported that the built-in `git add -p` command fails when asked to use [`diff-so-fancy`][diff-so-fancy] to colorize the diff. The reason is that this tool produces colored diffs with a hunk header that does not contain any parseable `@@ ... @@` line range information, and therefore we cannot detect any part in that header that comes after the line range. As proposed by Phillip Wood, let's take that for a clear indicator that we should show the hunk headers verbatim. This is what the Perl version of the interactive `add` command did, too. [diff-so-fancy]: https://github.com/so-fancy/diff-so-fancy Reported-by: Philippe Blain <levraiphilippeblain@gmail.com> Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | add -p: detect more mismatches between plain vs colored diffsJohannes Schindelin2022-09-011-1/+4
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When parsing the colored version of a diff, the interactive `add` command really relies on the colored version having the same number of lines as the plain (uncolored) version. That is an invariant. We already have code to verify correctly when the colored diff has less lines than the plain diff. Modulo an off-by-one bug: If the last diff line has no matching colored one, the code pretends to succeed, still. To make matters worse, when we adjusted the test in 1e4ffc765db (t3701: adjust difffilter test, 2020-01-14), we did not catch this because `add -p` fails for a _different_ reason: it does not find any colored hunk header that contains a parseable line range. If we change the test case so that the line range _can_ be parsed, the bug is exposed. Let's address all of the above by - fixing the off-by-one, - adjusting the test case to allow `add -p` to parse the line range - making the test case more stringent by verifying that the expected error message is shown Also adjust a misleading code comment about the now-fixed code. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* run-command API: rename "env_array" to "env"Ævar Arnfjörð Bjarmason2022-06-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Start following-up on the rename mentioned in c7c4bdeccf3 (run-command API: remove "env" member, always use "env_array", 2021-11-25) of "env_array" to "env". The "env_array" name was picked in 19a583dc39e (run-command: add env_array, an optional argv_array for env, 2014-10-19) because "env" was taken. Let's not forever keep the oddity of "*_array" for this "struct strvec", but not for its "args" sibling. This commit is almost entirely made with a coccinelle rule[1]. The only manual change here is in run-command.h to rename the struct member itself and to change "env_array" to "env" in the CHILD_PROCESS_INIT initializer. The rest of this is all a result of applying [1]: * make contrib/coccinelle/run_command.cocci.patch * patch -p1 <contrib/coccinelle/run_command.cocci.patch * git add -u 1. cat contrib/coccinelle/run_command.pending.cocci @@ struct child_process E; @@ - E.env_array + E.env @@ struct child_process *E; @@ - E->env_array + E->env I've avoided changing any comments and derived variable names here, that will all be done in the next commit. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'pw/add-p-hunk-split-fix'Junio C Hamano2022-02-091-7/+13
|\ | | | | | | | | | | | | | | | | "git add -p" rewritten in C regressed hunk splitting in some cases, which has been corrected. * pw/add-p-hunk-split-fix: builtin add -p: fix hunk splitting t3701: clean up hunk splitting tests
| * builtin add -p: fix hunk splittingPhillip Wood2022-01-121-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The C reimplementation of "add -p" fails to split the last hunk in a file if hunk ends with an addition or deletion without any post context line unless it is the last file to be processed. To determine whether a hunk can be split a counter is incremented each time a context line follows an insertion or deletion. If at the end of the hunk the value of this counter is greater than one then the hunk can be split into that number of smaller hunks. If the last hunk in a file ends with an insertion or deletion then there is no following context line and the counter will not be incremented. This case is already handled at the end of the loop where counter is incremented if the last hunk ended with an insertion or deletion. Unfortunately there is no similar check between files (likely because the perl version only ever parses one diff at a time). Fix this by checking if the last hunk ended with an insertion or deletion when we see the diff header of a new file and extend the existing regression test. Reproted-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | run-command API users: use strvec_pushv(), not argv assignmentÆvar Arnfjörð Bjarmason2021-11-251-2/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | Migrate those run-command API users that assign directly to the "argv" member to use a strvec_pushv() of "args" instead. In these cases it did not make sense to further refactor these callers, e.g. daemon.c could be made to construct the arguments closer to handle(), but that would require moving the construction from its cmd_main() and pass "argv" through two intermediate functions. It would be possible for a change like this to introduce a regression if we were doing: cp.argv = argv; argv[1] = "foo"; And changed the code, as is being done here, to: strvec_pushv(&cp.args, argv); argv[1] = "foo"; But as viewing this change with the "-W" flag reveals none of these functions modify variable that's being pushed afterwards in a way that would introduce such a logic error. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* *.c static functions: add missing __attribute__((format))Ævar Arnfjörð Bjarmason2021-07-131-0/+1
| | | | | | | | Add missing __attribute__((format)) function attributes to various "static" functions that take printf arguments. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'js/add-i-color-fix'Junio C Hamano2020-12-081-10/+15
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git add -i" failed to honor custom colors configured to show patches, which has been corrected. * js/add-i-color-fix: add -i: verify in the tests that colors can be overridden add -p: prefer color.diff.context over color.diff.plain add -i (Perl version): color header to match the C version add -i (built-in): use the same indentation as the Perl version add -p (built-in): do not color the progress indicator separately add -i (built-in): use correct names to load color.diff.* config add -i (built-in): prevent the `reset` "color" from being configured add -i: use `reset_color` consistently add -p (built-in): imitate `xdl_format_hunk_hdr()` generating hunk headers add -i (built-in): send error messages to stderr add -i (built-in): do show an error message for incorrect inputs
| * add -p (built-in): do not color the progress indicator separatelyJohannes Schindelin2020-11-161-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | The Perl version of this command colors the progress indicator and the prompt message in one go. Let's do the same in the built-in version so that the same upcoming test (which will compare the output of `git add -p` against a known-good version) will pass both for the Perl version as well as for the built-in version. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * add -i: use `reset_color` consistentlyJohannes Schindelin2020-11-111-2/+2
| | | | | | | | | | | | | | | | We already maintain a list of colors in the `add_i_state`, therefore we should use them. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * add -p (built-in): imitate `xdl_format_hunk_hdr()` generating hunk headersJohannes Schindelin2020-11-111-3/+8
| | | | | | | | | | | | | | | | | | | | In libxdiff, imitating GNU diff, the hunk headers only show the line count if it is different from 1. When splitting hunks, the Perl version of `git add -p` already imitates this. Let's do the same in the built-in version of said command. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'dl/checkout-p-merge-base'Junio C Hamano2020-10-271-0/+8
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | "git checkout -p A...B [-- <path>]" did not work, even though the same command without "-p" correctly used the merge-base between commits A and B. * dl/checkout-p-merge-base: t2016: add a NEEDSWORK about the PERL prerequisite add-patch: add NEEDSWORK about comparing commits Doc: document "A...B" form for <tree-ish> in checkout and switch builtin/checkout: fix `git checkout -p HEAD...` bug
| * add-patch: add NEEDSWORK about comparing commitsDenton Liu2020-10-071-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | The two versions of add-patch has special-casing for the literal revision "HEAD". However, we want to handle other ways of saying "HEAD" in the same way.[0] Add a NEEDSWORK to the add-patch code that does this so that it can be addressed later. [0]: https://lore.kernel.org/git/xmqqsgat7ttf.fsf@gitster.c.googlers.com/ Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'pw/add-p-edit-ita-path'Junio C Hamano2020-09-221-61/+79
|\ \ | | | | | | | | | | | | | | | | | | "add -p" now allows editing paths that were only added in intent. * pw/add-p-edit-ita-path: add -p: fix editing of intent-to-add paths
| * | add -p: fix editing of intent-to-add pathsPhillip Wood2020-09-091-61/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A popular way of partially staging a new file is to run `git add -N <path>` and then use the hunk editing of `git add -p` to select the part of the file that the user wishes to stage. Since 85953a3187 ("diff-files --raw: show correct post-image of intent-to-add files", 2020-07-01) this has stopped working as intent-to-add paths are now show as new files rather than changes to an empty blob and `git apply` refused to apply a creation patch for a path that was marked as intent-to-add. 7cfde3fa0f ("apply: allow "new file" patches on i-t-a entries", 2020-08-06) fixed the problem with apply but it still wasn't possible to edit the added hunk properly. 2c8bd8471a ("checkout -p: handle new files correctly", 2020-05-27) had previously changed `add -p` to handle new files but it did not implement patch editing correctly. The perl version simply forbade editing and the C version opened the editor with the full diff rather that just the hunk which meant that the user had to edit the hunk header manually to get it to work. The root cause of the problem is that added files store the diff header with the hunk data rather than separating the two as we do for other changes. Changing added files to store the diff header separately fixes the editing problem at the expense of having to special case empty additions as they no longer have any hunks associated with them, only the diff header. The changes move some existing code into a conditional changing the indentation, they are best viewed with --color-moved-ws=allow-indentation-change (or --ignore-space-change works well to get an overview of the changes) Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Reported-by: Thomas Sullivan <tom@msbit.com.au> Reported-by: Yuchen Ying <ych@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jk/add-i-fixes'Junio C Hamano2020-09-181-1/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | "add -i/-p" fixes. * jk/add-i-fixes: add--interactive.perl: specify --no-color explicitly add-patch: fix inverted return code of repo_read_index()
| * | | add-patch: fix inverted return code of repo_read_index()Jeff King2020-09-081-1/+1
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After applying hunks to a file with "add -p", the C patch_update_file() function tries to refresh the index (just like the perl version does). We can only refresh the index if we're able to read it in, so we first check the return value of repo_read_index(). But unlike many functions, where "0" is success, that function is documented to return the number of entries in the index. Hence we should be checking for success with a non-negative return value. Neither the tests nor any users seem to have noticed this, probably due to a combination of: - this affects only the C version, which is not yet the default - following it up with any porcelain command like "git diff" or "git commit" would refresh the index automatically. But you can see the problem by running the plumbing "git diff-files" immediately after "add -p" stages all hunks. Running the new test with GIT_TEST_ADD_I_USE_BUILTIN=1 fails without the matching code change. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'pw/add-p-leakfix'Junio C Hamano2020-09-181-8/+16
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | Leakfix. * pw/add-p-leakfix: add -p: fix memory leak
| * | add -p: fix memory leakPhillip Wood2020-09-081-8/+16
| |/ | | | | | | | | | | | | | | | | | | asan reports that the C version of `add -p` is not freeing all the memory it allocates. Fix this by introducing a function to clear `struct add_p_state` and use it instead of freeing individual members. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'pw/add-p-allowed-options-fix'Junio C Hamano2020-09-031-25/+42
|\ \ | | | | | | | | | | | | | | | | | | | | | "git add -p" update. * pw/add-p-allowed-options-fix: add -p: fix checking of user input add -p: use ALLOC_GROW_BY instead of ALLOW_GROW
| * | add -p: fix checking of user inputPhillip Wood2020-08-171-16/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a file has been deleted the C version of add -p allows the user to edit a hunk even though 'e' is not in the list of allowed responses. (I think 'e' is disallowed because if the file is edited it is no longer a deletion and we're not set up to rewrite the diff header). The invalid response was allowed because the test that determines whether to display 'e' was not duplicated correctly in the code that processes the user's choice. Fix this by using flags that are set when constructing the prompt and checked when processing the user's choice rather than repeating the check itself. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | add -p: use ALLOC_GROW_BY instead of ALLOW_GROWPhillip Wood2020-08-171-9/+4
| |/ | | | | | | | | | | | | | | This simplifies the code slightly, especially the third case where hunk_nr was incremented a few lines before ALLOC_GROW(). Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/strvec'Junio C Hamano2020-08-101-24/+24
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The argv_array API is useful for not just managing argv but any "vector" (NULL-terminated array) of strings, and has seen adoption to a certain degree. It has been renamed to "strvec" to reduce the barrier to adoption. * jk/strvec: strvec: rename struct fields strvec: drop argv_array compatibility layer strvec: update documention to avoid argv_array strvec: fix indentation in renamed calls strvec: convert remaining callers away from argv_array name strvec: convert more callers away from argv_array name strvec: convert builtin/ callers away from argv_array name quote: rename sq_dequote_to_argv_array to mention strvec strvec: rename files from argv-array to strvec argv-array: rename to strvec argv-array: use size_t for count and alloc
| * | strvec: rename struct fieldsJeff King2020-07-301-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "argc" and "argv" names made sense when the struct was argv_array, but now they're just confusing. Let's rename them to "nr" (which we use for counts elsewhere) and "v" (which is rather terse, but reads well when combined with typical variable names like "args.v"). Note that we have to update all of the callers immediately. Playing tricks with the preprocessor is hard here, because we wouldn't want to rewrite unrelated tokens. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | strvec: fix indentation in renamed callsJeff King2020-07-281-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Code which split an argv_array call across multiple lines, like: argv_array_pushl(&args, "one argument", "another argument", "and more", NULL); was recently mechanically renamed to use strvec, which results in mis-matched indentation like: strvec_pushl(&args, "one argument", "another argument", "and more", NULL); Let's fix these up to align the arguments with the opening paren. I did this manually by sifting through the results of: git jump grep 'strvec_.*,$' and liberally applying my editor's auto-format. Most of the changes are of the form shown above, though I also normalized a few that had originally used a single-tab indentation (rather than our usual style of aligning with the open paren). I also rewrapped a couple of obvious cases (e.g., where previously too-long lines became short enough to fit on one), but I wasn't aggressive about it. In cases broken to three or more lines, the grouping of arguments is sometimes meaningful, and it wasn't worth my time or reviewer time to ponder each case individually. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | strvec: convert more callers away from argv_array nameJeff King2020-07-281-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We eventually want to drop the argv_array name and just use strvec consistently. There's no particular reason we have to do it all at once, or care about interactions between converted and unconverted bits. Because of our preprocessor compat layer, the names are interchangeable to the compiler (so even a definition and declaration using different names is OK). This patch converts remaining files from the first half of the alphabet, to keep the diff to a manageable size. The conversion was done purely mechanically with: git ls-files '*.c' '*.h' | xargs perl -i -pe ' s/ARGV_ARRAY/STRVEC/g; s/argv_array/strvec/g; ' and then selectively staging files with "git add '[abcdefghjkl]*'". We'll deal with any indentation/style fallouts separately. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | strvec: rename files from argv-array to strvecJeff King2020-07-281-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | This requires updating #include lines across the code-base, but that's all fairly mechanical, and was done with: git ls-files '*.c' '*.h' | xargs perl -i -pe 's/argv-array.h/strvec.h/' Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | comment: fix spelling mistakes inside commentsSteve Kemp2020-07-291-1/+1
|/ | | | | | | | This commit fixes a couple of minor spelling mistakes inside comments. Signed-off-by: Steve Kemp <steve@steve.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'js/checkout-p-new-file'Junio C Hamano2020-06-081-7/+23
|\ | | | | | | | | | | | | "git checkout -p" did not handle a newly added path at all. * js/checkout-p-new-file: checkout -p: handle new files correctly
| * checkout -p: handle new files correctlyJohannes Schindelin2020-05-271-7/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original patch selection code was written for `git add -p`, and the fundamental unit on which it works is a hunk. We hacked around that to handle deletions back in 24ab81ae4d (add-interactive: handle deletion of empty files, 2009-10-27). But `git add -p` would never see a new file, since we only consider the set of tracked files in the index. However, since the same machinery was used for `git checkout -p` & friends, we can see new files. Handle this case specifically, adding a new prompt for it that is modeled after the `deleted file` case. This also fixes the problem where added _empty_ files could not be staged via `git checkout -p`. Reported-by: Merlin Büge <toni@bluenox07.de> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | interactive: refactor code asking the user for interactive inputJohannes Schindelin2020-04-101-2/+2
|/ | | | | | | | | | | | | | | | There are quite a few code locations (e.g. `git clean --interactive`) where Git asks the user for an answer. In preparation for fixing a bug shared by all of them, and also to DRY up the code, let's refactor it. Please note that most of these callers trimmed white-space both at the beginning and at the end of the answer, instead of trimming only the end (as the caller in `add-patch.c` does). Therefore, technically speaking, we change behavior in this patch. At the same time, it can be argued that this is actually a bug fix. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* built-in add -p: respect the `interactive.singlekey` config settingJohannes Schindelin2020-01-151-4/+17
| | | | | | | | | | | | | | | | | | | | The Perl version of `git add -p` supports this config setting to allow users to input commands via single characters (as opposed to having to press the <Enter> key afterwards). This is an opt-in feature because it requires Perl packages (Term::ReadKey and Term::Cap, where it tries to handle an absence of the latter package gracefully) to work. Note that at least on Ubuntu, that Perl package is not installed by default (it needs to be installed via `sudo apt-get install libterm-readkey-perl`), so this feature is probably not used a whole lot. In C, we obviously do not have these packages available, but we just introduced `read_single_keystroke()` that is similar to what Term::ReadKey provides, and we use that here. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* built-in add -p: handle diff.algorithmJohannes Schindelin2020-01-151-0/+3
| | | | | | | | | | | | | | | The Perl version of `git add -p` reads the config setting `diff.algorithm` and if set, uses it to generate the diff using the specified algorithm. This patch ports that functionality to the C version. Note: just like `git-add--interactive.perl`, we do _not_ respect this config setting in `git add -i`'s `diff` command, but _only_ in the `patch` command. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* built-in add -p: support interactive.diffFilterJohannes Schindelin2020-01-151-0/+33
| | | | | | | | | | The Perl version supports post-processing the colored diff (that is generated in addition to the uncolored diff, intended to offer a prettier user experience) by a command configured via that config setting, and now the built-in version does that, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
View Lorry Controller Status