2023-05-16 14:33:57 +08:00
|
|
|
#include "git-compat-util.h"
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
#include "add-interactive.h"
|
2023-04-11 11:00:39 +08:00
|
|
|
#include "advice.h"
|
2023-04-11 15:41:57 +08:00
|
|
|
#include "editor.h"
|
2023-03-21 14:25:57 +08:00
|
|
|
#include "environment.h"
|
2023-03-21 14:25:54 +08:00
|
|
|
#include "gettext.h"
|
2023-04-11 15:41:49 +08:00
|
|
|
#include "object-name.h"
|
2023-05-16 14:33:56 +08:00
|
|
|
#include "read-cache-ll.h"
|
2023-05-16 14:34:00 +08:00
|
|
|
#include "repository.h"
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
#include "strbuf.h"
|
|
|
|
#include "run-command.h"
|
2020-07-29 04:23:39 +08:00
|
|
|
#include "strvec.h"
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
#include "pathspec.h"
|
2019-12-13 16:07:50 +08:00
|
|
|
#include "color.h"
|
2020-01-15 02:43:50 +08:00
|
|
|
#include "compat/terminal.h"
|
2020-04-10 19:27:50 +08:00
|
|
|
#include "prompt.h"
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
|
2019-12-13 16:07:57 +08:00
|
|
|
enum prompt_mode_type {
|
2020-05-28 05:09:06 +08:00
|
|
|
PROMPT_MODE_CHANGE = 0, PROMPT_DELETION, PROMPT_ADDITION, PROMPT_HUNK,
|
2019-12-22 05:57:10 +08:00
|
|
|
PROMPT_MODE_MAX, /* must be last */
|
2019-12-13 16:07:57 +08:00
|
|
|
};
|
|
|
|
|
2019-12-22 05:57:10 +08:00
|
|
|
struct patch_mode {
|
|
|
|
/*
|
|
|
|
* The magic constant 4 is chosen such that all patch modes
|
|
|
|
* provide enough space for three command-line arguments followed by a
|
|
|
|
* trailing `NULL`.
|
|
|
|
*/
|
|
|
|
const char *diff_cmd[4], *apply_args[4], *apply_check_args[4];
|
2019-12-22 05:57:11 +08:00
|
|
|
unsigned is_reverse:1, index_only:1, apply_for_checkout:1;
|
2019-12-22 05:57:10 +08:00
|
|
|
const char *prompt_mode[PROMPT_MODE_MAX];
|
|
|
|
const char *edit_hunk_hint, *help_patch_text;
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct patch_mode patch_mode_add = {
|
|
|
|
.diff_cmd = { "diff-files", NULL },
|
|
|
|
.apply_args = { "--cached", NULL },
|
|
|
|
.apply_check_args = { "--cached", NULL },
|
|
|
|
.prompt_mode = {
|
|
|
|
N_("Stage mode change [y,n,q,a,d%s,?]? "),
|
|
|
|
N_("Stage deletion [y,n,q,a,d%s,?]? "),
|
2020-05-28 05:09:06 +08:00
|
|
|
N_("Stage addition [y,n,q,a,d%s,?]? "),
|
2019-12-22 05:57:10 +08:00
|
|
|
N_("Stage this hunk [y,n,q,a,d%s,?]? ")
|
|
|
|
},
|
|
|
|
.edit_hunk_hint = N_("If the patch applies cleanly, the edited hunk "
|
|
|
|
"will immediately be marked for staging."),
|
|
|
|
.help_patch_text =
|
|
|
|
N_("y - stage this hunk\n"
|
|
|
|
"n - do not stage this hunk\n"
|
|
|
|
"q - quit; do not stage this hunk or any of the remaining "
|
|
|
|
"ones\n"
|
|
|
|
"a - stage this hunk and all later hunks in the file\n"
|
|
|
|
"d - do not stage this hunk or any of the later hunks in "
|
|
|
|
"the file\n")
|
2019-12-13 16:07:57 +08:00
|
|
|
};
|
|
|
|
|
2019-12-22 05:57:11 +08:00
|
|
|
static struct patch_mode patch_mode_stash = {
|
|
|
|
.diff_cmd = { "diff-index", "HEAD", NULL },
|
|
|
|
.apply_args = { "--cached", NULL },
|
|
|
|
.apply_check_args = { "--cached", NULL },
|
|
|
|
.prompt_mode = {
|
|
|
|
N_("Stash mode change [y,n,q,a,d%s,?]? "),
|
|
|
|
N_("Stash deletion [y,n,q,a,d%s,?]? "),
|
2020-05-28 05:09:06 +08:00
|
|
|
N_("Stash addition [y,n,q,a,d%s,?]? "),
|
2019-12-22 05:57:11 +08:00
|
|
|
N_("Stash this hunk [y,n,q,a,d%s,?]? "),
|
|
|
|
},
|
|
|
|
.edit_hunk_hint = N_("If the patch applies cleanly, the edited hunk "
|
|
|
|
"will immediately be marked for stashing."),
|
|
|
|
.help_patch_text =
|
|
|
|
N_("y - stash this hunk\n"
|
|
|
|
"n - do not stash this hunk\n"
|
|
|
|
"q - quit; do not stash this hunk or any of the remaining "
|
|
|
|
"ones\n"
|
|
|
|
"a - stash this hunk and all later hunks in the file\n"
|
|
|
|
"d - do not stash this hunk or any of the later hunks in "
|
|
|
|
"the file\n"),
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct patch_mode patch_mode_reset_head = {
|
|
|
|
.diff_cmd = { "diff-index", "--cached", NULL },
|
|
|
|
.apply_args = { "-R", "--cached", NULL },
|
|
|
|
.apply_check_args = { "-R", "--cached", NULL },
|
|
|
|
.is_reverse = 1,
|
|
|
|
.index_only = 1,
|
|
|
|
.prompt_mode = {
|
|
|
|
N_("Unstage mode change [y,n,q,a,d%s,?]? "),
|
|
|
|
N_("Unstage deletion [y,n,q,a,d%s,?]? "),
|
2020-05-28 05:09:06 +08:00
|
|
|
N_("Unstage addition [y,n,q,a,d%s,?]? "),
|
2019-12-22 05:57:11 +08:00
|
|
|
N_("Unstage this hunk [y,n,q,a,d%s,?]? "),
|
|
|
|
},
|
|
|
|
.edit_hunk_hint = N_("If the patch applies cleanly, the edited hunk "
|
|
|
|
"will immediately be marked for unstaging."),
|
|
|
|
.help_patch_text =
|
|
|
|
N_("y - unstage this hunk\n"
|
|
|
|
"n - do not unstage this hunk\n"
|
|
|
|
"q - quit; do not unstage this hunk or any of the remaining "
|
|
|
|
"ones\n"
|
|
|
|
"a - unstage this hunk and all later hunks in the file\n"
|
|
|
|
"d - do not unstage this hunk or any of the later hunks in "
|
|
|
|
"the file\n"),
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct patch_mode patch_mode_reset_nothead = {
|
|
|
|
.diff_cmd = { "diff-index", "-R", "--cached", NULL },
|
|
|
|
.apply_args = { "--cached", NULL },
|
|
|
|
.apply_check_args = { "--cached", NULL },
|
|
|
|
.index_only = 1,
|
|
|
|
.prompt_mode = {
|
|
|
|
N_("Apply mode change to index [y,n,q,a,d%s,?]? "),
|
|
|
|
N_("Apply deletion to index [y,n,q,a,d%s,?]? "),
|
2020-05-28 05:09:06 +08:00
|
|
|
N_("Apply addition to index [y,n,q,a,d%s,?]? "),
|
2019-12-22 05:57:11 +08:00
|
|
|
N_("Apply this hunk to index [y,n,q,a,d%s,?]? "),
|
|
|
|
},
|
|
|
|
.edit_hunk_hint = N_("If the patch applies cleanly, the edited hunk "
|
|
|
|
"will immediately be marked for applying."),
|
|
|
|
.help_patch_text =
|
|
|
|
N_("y - apply this hunk to index\n"
|
|
|
|
"n - do not apply this hunk to index\n"
|
|
|
|
"q - quit; do not apply this hunk or any of the remaining "
|
|
|
|
"ones\n"
|
|
|
|
"a - apply this hunk and all later hunks in the file\n"
|
|
|
|
"d - do not apply this hunk or any of the later hunks in "
|
|
|
|
"the file\n"),
|
|
|
|
};
|
|
|
|
|
2019-12-22 05:57:14 +08:00
|
|
|
static struct patch_mode patch_mode_checkout_index = {
|
|
|
|
.diff_cmd = { "diff-files", NULL },
|
|
|
|
.apply_args = { "-R", NULL },
|
|
|
|
.apply_check_args = { "-R", NULL },
|
|
|
|
.is_reverse = 1,
|
|
|
|
.prompt_mode = {
|
|
|
|
N_("Discard mode change from worktree [y,n,q,a,d%s,?]? "),
|
|
|
|
N_("Discard deletion from worktree [y,n,q,a,d%s,?]? "),
|
2020-05-28 05:09:06 +08:00
|
|
|
N_("Discard addition from worktree [y,n,q,a,d%s,?]? "),
|
2019-12-22 05:57:14 +08:00
|
|
|
N_("Discard this hunk from worktree [y,n,q,a,d%s,?]? "),
|
|
|
|
},
|
|
|
|
.edit_hunk_hint = N_("If the patch applies cleanly, the edited hunk "
|
|
|
|
"will immediately be marked for discarding."),
|
|
|
|
.help_patch_text =
|
|
|
|
N_("y - discard this hunk from worktree\n"
|
|
|
|
"n - do not discard this hunk from worktree\n"
|
|
|
|
"q - quit; do not discard this hunk or any of the remaining "
|
|
|
|
"ones\n"
|
|
|
|
"a - discard this hunk and all later hunks in the file\n"
|
|
|
|
"d - do not discard this hunk or any of the later hunks in "
|
|
|
|
"the file\n"),
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct patch_mode patch_mode_checkout_head = {
|
|
|
|
.diff_cmd = { "diff-index", NULL },
|
|
|
|
.apply_for_checkout = 1,
|
|
|
|
.apply_check_args = { "-R", NULL },
|
|
|
|
.is_reverse = 1,
|
|
|
|
.prompt_mode = {
|
|
|
|
N_("Discard mode change from index and worktree [y,n,q,a,d%s,?]? "),
|
|
|
|
N_("Discard deletion from index and worktree [y,n,q,a,d%s,?]? "),
|
2020-05-28 05:09:06 +08:00
|
|
|
N_("Discard addition from index and worktree [y,n,q,a,d%s,?]? "),
|
2019-12-22 05:57:14 +08:00
|
|
|
N_("Discard this hunk from index and worktree [y,n,q,a,d%s,?]? "),
|
|
|
|
},
|
|
|
|
.edit_hunk_hint = N_("If the patch applies cleanly, the edited hunk "
|
|
|
|
"will immediately be marked for discarding."),
|
|
|
|
.help_patch_text =
|
|
|
|
N_("y - discard this hunk from index and worktree\n"
|
|
|
|
"n - do not discard this hunk from index and worktree\n"
|
|
|
|
"q - quit; do not discard this hunk or any of the remaining "
|
|
|
|
"ones\n"
|
|
|
|
"a - discard this hunk and all later hunks in the file\n"
|
|
|
|
"d - do not discard this hunk or any of the later hunks in "
|
|
|
|
"the file\n"),
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct patch_mode patch_mode_checkout_nothead = {
|
|
|
|
.diff_cmd = { "diff-index", "-R", NULL },
|
|
|
|
.apply_for_checkout = 1,
|
|
|
|
.apply_check_args = { NULL },
|
|
|
|
.prompt_mode = {
|
|
|
|
N_("Apply mode change to index and worktree [y,n,q,a,d%s,?]? "),
|
|
|
|
N_("Apply deletion to index and worktree [y,n,q,a,d%s,?]? "),
|
2020-05-28 05:09:06 +08:00
|
|
|
N_("Apply addition to index and worktree [y,n,q,a,d%s,?]? "),
|
2019-12-22 05:57:14 +08:00
|
|
|
N_("Apply this hunk to index and worktree [y,n,q,a,d%s,?]? "),
|
|
|
|
},
|
|
|
|
.edit_hunk_hint = N_("If the patch applies cleanly, the edited hunk "
|
|
|
|
"will immediately be marked for applying."),
|
|
|
|
.help_patch_text =
|
|
|
|
N_("y - apply this hunk to index and worktree\n"
|
|
|
|
"n - do not apply this hunk to index and worktree\n"
|
|
|
|
"q - quit; do not apply this hunk or any of the remaining "
|
|
|
|
"ones\n"
|
|
|
|
"a - apply this hunk and all later hunks in the file\n"
|
|
|
|
"d - do not apply this hunk or any of the later hunks in "
|
|
|
|
"the file\n"),
|
|
|
|
};
|
|
|
|
|
2019-12-22 05:57:15 +08:00
|
|
|
static struct patch_mode patch_mode_worktree_head = {
|
|
|
|
.diff_cmd = { "diff-index", NULL },
|
|
|
|
.apply_args = { "-R", NULL },
|
|
|
|
.apply_check_args = { "-R", NULL },
|
|
|
|
.is_reverse = 1,
|
|
|
|
.prompt_mode = {
|
2022-09-14 17:47:33 +08:00
|
|
|
N_("Discard mode change from worktree [y,n,q,a,d%s,?]? "),
|
|
|
|
N_("Discard deletion from worktree [y,n,q,a,d%s,?]? "),
|
|
|
|
N_("Discard addition from worktree [y,n,q,a,d%s,?]? "),
|
|
|
|
N_("Discard this hunk from worktree [y,n,q,a,d%s,?]? "),
|
2019-12-22 05:57:15 +08:00
|
|
|
},
|
|
|
|
.edit_hunk_hint = N_("If the patch applies cleanly, the edited hunk "
|
|
|
|
"will immediately be marked for discarding."),
|
|
|
|
.help_patch_text =
|
|
|
|
N_("y - discard this hunk from worktree\n"
|
|
|
|
"n - do not discard this hunk from worktree\n"
|
|
|
|
"q - quit; do not discard this hunk or any of the remaining "
|
|
|
|
"ones\n"
|
|
|
|
"a - discard this hunk and all later hunks in the file\n"
|
|
|
|
"d - do not discard this hunk or any of the later hunks in "
|
|
|
|
"the file\n"),
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct patch_mode patch_mode_worktree_nothead = {
|
|
|
|
.diff_cmd = { "diff-index", "-R", NULL },
|
|
|
|
.apply_args = { NULL },
|
|
|
|
.apply_check_args = { NULL },
|
|
|
|
.prompt_mode = {
|
2022-09-14 17:47:33 +08:00
|
|
|
N_("Apply mode change to worktree [y,n,q,a,d%s,?]? "),
|
|
|
|
N_("Apply deletion to worktree [y,n,q,a,d%s,?]? "),
|
|
|
|
N_("Apply addition to worktree [y,n,q,a,d%s,?]? "),
|
|
|
|
N_("Apply this hunk to worktree [y,n,q,a,d%s,?]? "),
|
2019-12-22 05:57:15 +08:00
|
|
|
},
|
|
|
|
.edit_hunk_hint = N_("If the patch applies cleanly, the edited hunk "
|
|
|
|
"will immediately be marked for applying."),
|
|
|
|
.help_patch_text =
|
|
|
|
N_("y - apply this hunk to worktree\n"
|
|
|
|
"n - do not apply this hunk to worktree\n"
|
|
|
|
"q - quit; do not apply this hunk or any of the remaining "
|
|
|
|
"ones\n"
|
|
|
|
"a - apply this hunk and all later hunks in the file\n"
|
|
|
|
"d - do not apply this hunk or any of the later hunks in "
|
|
|
|
"the file\n"),
|
|
|
|
};
|
|
|
|
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
struct hunk_header {
|
|
|
|
unsigned long old_offset, old_count, new_offset, new_count;
|
|
|
|
/*
|
|
|
|
* Start/end offsets to the extra text after the second `@@` in the
|
|
|
|
* hunk header, e.g. the function signature. This is expected to
|
|
|
|
* include the newline.
|
|
|
|
*/
|
|
|
|
size_t extra_start, extra_end, colored_extra_start, colored_extra_end;
|
2022-09-01 23:42:18 +08:00
|
|
|
unsigned suppress_colored_line_range:1;
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
};
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
|
|
|
|
struct hunk {
|
built-in add -p: implement the hunk splitting feature
If this developer's workflow is any indication, then this is *the* most
useful feature of Git's interactive `add `command.
Note: once again, this is not a verbatim conversion from the Perl code
to C: the `hunk_splittable()` function, for example, essentially did all
the work of splitting the hunk, just to find out whether more than one
hunk would have been the result (and then tossed that result into the
trash). In C we instead count the number of resulting hunks (without
actually doing the work of splitting, but just counting the transitions
from non-context lines to context lines), and store that information
with the hunk, and we do that *while* parsing the diff in the first
place.
Another deviation: the built-in `git add -p` was designed with a single
strbuf holding the diff (and another one holding the colored diff, if
that one was asked for) in mind, and hunks essentially store just the
start and end offsets pointing into that strbuf. As a consequence, when
we split hunks, we now use a special mode where the hunk header is
generated dynamically, and only the rest of the hunk is stored using
such start/end offsets. This way, we also avoid the frequent
formatting/re-parsing of the hunk header of the Perl version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:58 +08:00
|
|
|
size_t start, end, colored_start, colored_end, splittable_into;
|
2019-12-13 16:08:01 +08:00
|
|
|
ssize_t delta;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
enum { UNDECIDED_HUNK = 0, SKIP_HUNK, USE_HUNK } use;
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
struct hunk_header header;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct add_p_state {
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
struct add_i_state s;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
struct strbuf answer, buf;
|
|
|
|
|
|
|
|
/* parsed diff */
|
2019-12-13 16:07:50 +08:00
|
|
|
struct strbuf plain, colored;
|
2019-12-13 16:07:54 +08:00
|
|
|
struct file_diff {
|
|
|
|
struct hunk head;
|
|
|
|
struct hunk *hunk;
|
|
|
|
size_t hunk_nr, hunk_alloc;
|
2020-05-28 05:09:06 +08:00
|
|
|
unsigned deleted:1, added:1, mode_change:1,binary:1;
|
2019-12-13 16:07:54 +08:00
|
|
|
} *file_diff;
|
|
|
|
size_t file_diff_nr;
|
2019-12-22 05:57:10 +08:00
|
|
|
|
|
|
|
/* patch mode */
|
|
|
|
struct patch_mode *mode;
|
|
|
|
const char *revision;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
};
|
|
|
|
|
2020-09-07 23:04:00 +08:00
|
|
|
static void add_p_state_clear(struct add_p_state *s)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
strbuf_release(&s->answer);
|
|
|
|
strbuf_release(&s->buf);
|
|
|
|
strbuf_release(&s->plain);
|
|
|
|
strbuf_release(&s->colored);
|
|
|
|
for (i = 0; i < s->file_diff_nr; i++)
|
|
|
|
free(s->file_diff[i].hunk);
|
|
|
|
free(s->file_diff);
|
|
|
|
clear_add_i_state(&s->s);
|
|
|
|
}
|
|
|
|
|
2021-07-13 16:05:18 +08:00
|
|
|
__attribute__((format (printf, 2, 3)))
|
2019-12-13 16:07:53 +08:00
|
|
|
static void err(struct add_p_state *s, const char *fmt, ...)
|
|
|
|
{
|
|
|
|
va_list args;
|
|
|
|
|
|
|
|
va_start(args, fmt);
|
2024-04-30 02:37:03 +08:00
|
|
|
fputs(s->s.error_color, stdout);
|
|
|
|
vprintf(fmt, args);
|
|
|
|
puts(s->s.reset_color);
|
2019-12-13 16:07:53 +08:00
|
|
|
va_end(args);
|
|
|
|
}
|
|
|
|
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
static void setup_child_process(struct add_p_state *s,
|
|
|
|
struct child_process *cp, ...)
|
|
|
|
{
|
|
|
|
va_list ap;
|
|
|
|
const char *arg;
|
|
|
|
|
|
|
|
va_start(ap, cp);
|
|
|
|
while ((arg = va_arg(ap, const char *)))
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_push(&cp->args, arg);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
va_end(ap);
|
|
|
|
|
|
|
|
cp->git_cmd = 1;
|
2022-06-02 17:09:50 +08:00
|
|
|
strvec_pushf(&cp->env,
|
strvec: fix indentation in renamed calls
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>
2020-07-29 04:26:31 +08:00
|
|
|
INDEX_ENVIRONMENT "=%s", s->s.r->index_file);
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int parse_range(const char **p,
|
|
|
|
unsigned long *offset, unsigned long *count)
|
|
|
|
{
|
|
|
|
char *pend;
|
|
|
|
|
|
|
|
*offset = strtoul(*p, &pend, 10);
|
|
|
|
if (pend == *p)
|
|
|
|
return -1;
|
|
|
|
if (*pend != ',') {
|
|
|
|
*count = 1;
|
|
|
|
*p = pend;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
*count = strtoul(pend + 1, (char **)p, 10);
|
|
|
|
return *p == pend + 1 ? -1 : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int parse_hunk_header(struct add_p_state *s, struct hunk *hunk)
|
|
|
|
{
|
|
|
|
struct hunk_header *header = &hunk->header;
|
|
|
|
const char *line = s->plain.buf + hunk->start, *p = line;
|
|
|
|
char *eol = memchr(p, '\n', s->plain.len - hunk->start);
|
|
|
|
|
|
|
|
if (!eol)
|
|
|
|
eol = s->plain.buf + s->plain.len;
|
|
|
|
|
|
|
|
if (!skip_prefix(p, "@@ -", &p) ||
|
|
|
|
parse_range(&p, &header->old_offset, &header->old_count) < 0 ||
|
|
|
|
!skip_prefix(p, " +", &p) ||
|
|
|
|
parse_range(&p, &header->new_offset, &header->new_count) < 0 ||
|
|
|
|
!skip_prefix(p, " @@", &p))
|
|
|
|
return error(_("could not parse hunk header '%.*s'"),
|
|
|
|
(int)(eol - line), line);
|
|
|
|
|
|
|
|
hunk->start = eol - s->plain.buf + (*eol == '\n');
|
|
|
|
header->extra_start = p - s->plain.buf;
|
|
|
|
header->extra_end = hunk->start;
|
|
|
|
|
|
|
|
if (!s->colored.len) {
|
|
|
|
header->colored_extra_start = header->colored_extra_end = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now find the extra text in the colored diff */
|
|
|
|
line = s->colored.buf + hunk->colored_start;
|
|
|
|
eol = memchr(line, '\n', s->colored.len - hunk->colored_start);
|
|
|
|
if (!eol)
|
|
|
|
eol = s->colored.buf + s->colored.len;
|
|
|
|
p = memmem(line, eol - line, "@@ -", 4);
|
2022-09-01 23:42:18 +08:00
|
|
|
if (p && (p = memmem(p + 4, eol - p - 4, " @@", 3))) {
|
|
|
|
header->colored_extra_start = p + 3 - s->colored.buf;
|
|
|
|
} else {
|
|
|
|
/* could not parse colored hunk header, leave as-is */
|
|
|
|
header->colored_extra_start = hunk->colored_start;
|
|
|
|
header->suppress_colored_line_range = 1;
|
|
|
|
}
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
hunk->colored_start = eol - s->colored.buf + (*eol == '\n');
|
|
|
|
header->colored_extra_end = hunk->colored_start;
|
|
|
|
|
|
|
|
return 0;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
}
|
|
|
|
|
2019-12-13 16:07:56 +08:00
|
|
|
static int is_octal(const char *p, size_t len)
|
|
|
|
{
|
|
|
|
if (!len)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
while (len--)
|
|
|
|
if (*p < '0' || *(p++) > '7')
|
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2022-01-11 19:12:10 +08:00
|
|
|
static void complete_file(char marker, struct hunk *hunk)
|
|
|
|
{
|
|
|
|
if (marker == '-' || marker == '+')
|
|
|
|
/*
|
|
|
|
* Last hunk ended in non-context line (i.e. it
|
|
|
|
* appended lines to the file, so there are no
|
|
|
|
* trailing context lines).
|
|
|
|
*/
|
|
|
|
hunk->splittable_into++;
|
|
|
|
}
|
|
|
|
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
static int parse_diff(struct add_p_state *s, const struct pathspec *ps)
|
|
|
|
{
|
2020-07-29 04:24:53 +08:00
|
|
|
struct strvec args = STRVEC_INIT;
|
2020-01-15 02:43:46 +08:00
|
|
|
const char *diff_algorithm = s->s.interactive_diff_algorithm;
|
2019-12-13 16:07:50 +08:00
|
|
|
struct strbuf *plain = &s->plain, *colored = NULL;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
struct child_process cp = CHILD_PROCESS_INIT;
|
built-in add -p: implement the hunk splitting feature
If this developer's workflow is any indication, then this is *the* most
useful feature of Git's interactive `add `command.
Note: once again, this is not a verbatim conversion from the Perl code
to C: the `hunk_splittable()` function, for example, essentially did all
the work of splitting the hunk, just to find out whether more than one
hunk would have been the result (and then tossed that result into the
trash). In C we instead count the number of resulting hunks (without
actually doing the work of splitting, but just counting the transitions
from non-context lines to context lines), and store that information
with the hunk, and we do that *while* parsing the diff in the first
place.
Another deviation: the built-in `git add -p` was designed with a single
strbuf holding the diff (and another one holding the colored diff, if
that one was asked for) in mind, and hunks essentially store just the
start and end offsets pointing into that strbuf. As a consequence, when
we split hunks, we now use a special mode where the hunk header is
generated dynamically, and only the rest of the hunk is stored using
such start/end offsets. This way, we also avoid the frequent
formatting/re-parsing of the hunk header of the Perl version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:58 +08:00
|
|
|
char *p, *pend, *colored_p = NULL, *colored_pend = NULL, marker = '\0';
|
2019-12-13 16:07:54 +08:00
|
|
|
size_t file_diff_alloc = 0, i, color_arg_index;
|
|
|
|
struct file_diff *file_diff = NULL;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
struct hunk *hunk = NULL;
|
|
|
|
int res;
|
|
|
|
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_pushv(&args, s->mode->diff_cmd);
|
2020-01-15 02:43:46 +08:00
|
|
|
if (diff_algorithm)
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_pushf(&args, "--diff-algorithm=%s", diff_algorithm);
|
2019-12-22 05:57:10 +08:00
|
|
|
if (s->revision) {
|
|
|
|
struct object_id oid;
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_push(&args,
|
strvec: fix indentation in renamed calls
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>
2020-07-29 04:26:31 +08:00
|
|
|
/* could be on an unborn branch */
|
|
|
|
!strcmp("HEAD", s->revision) &&
|
2023-03-28 21:58:46 +08:00
|
|
|
repo_get_oid(the_repository, "HEAD", &oid) ?
|
strvec: fix indentation in renamed calls
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>
2020-07-29 04:26:31 +08:00
|
|
|
empty_tree_oid_hex() : s->revision);
|
2019-12-22 05:57:10 +08:00
|
|
|
}
|
2020-07-29 08:37:20 +08:00
|
|
|
color_arg_index = args.nr;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
/* Use `--no-color` explicitly, just in case `diff.color = always`. */
|
2022-09-01 23:42:19 +08:00
|
|
|
strvec_pushl(&args, "--no-color", "--ignore-submodules=dirty", "-p",
|
|
|
|
"--", NULL);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
for (i = 0; i < ps->nr; i++)
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_push(&args, ps->items[i].original);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
|
2019-12-13 16:07:50 +08:00
|
|
|
setup_child_process(s, &cp, NULL);
|
2021-11-26 06:52:18 +08:00
|
|
|
strvec_pushv(&cp.args, args.v);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
res = capture_command(&cp, plain, 0);
|
2019-12-13 16:07:50 +08:00
|
|
|
if (res) {
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_clear(&args);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
return error(_("could not parse diff"));
|
2019-12-13 16:07:50 +08:00
|
|
|
}
|
|
|
|
if (!plain->len) {
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_clear(&args);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
return 0;
|
2019-12-13 16:07:50 +08:00
|
|
|
}
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
strbuf_complete_line(plain);
|
|
|
|
|
2019-12-13 16:07:50 +08:00
|
|
|
if (want_color_fd(1, -1)) {
|
|
|
|
struct child_process colored_cp = CHILD_PROCESS_INIT;
|
2020-01-15 02:43:45 +08:00
|
|
|
const char *diff_filter = s->s.interactive_diff_filter;
|
2019-12-13 16:07:50 +08:00
|
|
|
|
|
|
|
setup_child_process(s, &colored_cp, NULL);
|
2020-07-29 08:37:20 +08:00
|
|
|
xsnprintf((char *)args.v[color_arg_index], 8, "--color");
|
2021-11-26 06:52:18 +08:00
|
|
|
strvec_pushv(&colored_cp.args, args.v);
|
2019-12-13 16:07:50 +08:00
|
|
|
colored = &s->colored;
|
|
|
|
res = capture_command(&colored_cp, colored, 0);
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_clear(&args);
|
2019-12-13 16:07:50 +08:00
|
|
|
if (res)
|
|
|
|
return error(_("could not parse colored diff"));
|
2020-01-15 02:43:45 +08:00
|
|
|
|
|
|
|
if (diff_filter) {
|
|
|
|
struct child_process filter_cp = CHILD_PROCESS_INIT;
|
|
|
|
|
|
|
|
setup_child_process(s, &filter_cp,
|
|
|
|
diff_filter, NULL);
|
|
|
|
filter_cp.git_cmd = 0;
|
|
|
|
filter_cp.use_shell = 1;
|
|
|
|
strbuf_reset(&s->buf);
|
|
|
|
if (pipe_command(&filter_cp,
|
|
|
|
colored->buf, colored->len,
|
|
|
|
&s->buf, colored->len,
|
|
|
|
NULL, 0) < 0)
|
|
|
|
return error(_("failed to run '%s'"),
|
|
|
|
diff_filter);
|
|
|
|
strbuf_swap(colored, &s->buf);
|
|
|
|
}
|
|
|
|
|
2019-12-13 16:07:50 +08:00
|
|
|
strbuf_complete_line(colored);
|
|
|
|
colored_p = colored->buf;
|
|
|
|
colored_pend = colored_p + colored->len;
|
|
|
|
}
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_clear(&args);
|
2019-12-13 16:07:50 +08:00
|
|
|
|
2019-12-13 16:07:54 +08:00
|
|
|
/* parse files and hunks */
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
p = plain->buf;
|
|
|
|
pend = p + plain->len;
|
|
|
|
while (p != pend) {
|
|
|
|
char *eol = memchr(p, '\n', pend - p);
|
2020-09-09 21:58:52 +08:00
|
|
|
const char *deleted = NULL, *mode_change = NULL;
|
2019-12-13 16:07:55 +08:00
|
|
|
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
if (!eol)
|
|
|
|
eol = pend;
|
|
|
|
|
add-patch: handle "* Unmerged path" lines
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>
2023-03-09 16:58:16 +08:00
|
|
|
if (starts_with(p, "diff ") ||
|
|
|
|
starts_with(p, "* Unmerged path ")) {
|
2022-01-11 19:12:10 +08:00
|
|
|
complete_file(marker, hunk);
|
2020-08-17 21:23:07 +08:00
|
|
|
ALLOC_GROW_BY(s->file_diff, s->file_diff_nr, 1,
|
2019-12-13 16:07:54 +08:00
|
|
|
file_diff_alloc);
|
|
|
|
file_diff = s->file_diff + s->file_diff_nr - 1;
|
|
|
|
hunk = &file_diff->head;
|
|
|
|
hunk->start = p - plain->buf;
|
|
|
|
if (colored_p)
|
|
|
|
hunk->colored_start = colored_p - colored->buf;
|
built-in add -p: implement the hunk splitting feature
If this developer's workflow is any indication, then this is *the* most
useful feature of Git's interactive `add `command.
Note: once again, this is not a verbatim conversion from the Perl code
to C: the `hunk_splittable()` function, for example, essentially did all
the work of splitting the hunk, just to find out whether more than one
hunk would have been the result (and then tossed that result into the
trash). In C we instead count the number of resulting hunks (without
actually doing the work of splitting, but just counting the transitions
from non-context lines to context lines), and store that information
with the hunk, and we do that *while* parsing the diff in the first
place.
Another deviation: the built-in `git add -p` was designed with a single
strbuf holding the diff (and another one holding the colored diff, if
that one was asked for) in mind, and hunks essentially store just the
start and end offsets pointing into that strbuf. As a consequence, when
we split hunks, we now use a special mode where the hunk header is
generated dynamically, and only the rest of the hunk is stored using
such start/end offsets. This way, we also avoid the frequent
formatting/re-parsing of the hunk header of the Perl version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:58 +08:00
|
|
|
marker = '\0';
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
} else if (p == plain->buf)
|
|
|
|
BUG("diff starts with unexpected line:\n"
|
|
|
|
"%.*s\n", (int)(eol - p), p);
|
2020-09-09 21:58:52 +08:00
|
|
|
else if (file_diff->deleted)
|
2019-12-13 16:07:55 +08:00
|
|
|
; /* keep the rest of the file in a single "hunk" */
|
|
|
|
else if (starts_with(p, "@@ ") ||
|
|
|
|
(hunk == &file_diff->head &&
|
2020-09-09 21:58:52 +08:00
|
|
|
(skip_prefix(p, "deleted file", &deleted)))) {
|
built-in add -p: implement the hunk splitting feature
If this developer's workflow is any indication, then this is *the* most
useful feature of Git's interactive `add `command.
Note: once again, this is not a verbatim conversion from the Perl code
to C: the `hunk_splittable()` function, for example, essentially did all
the work of splitting the hunk, just to find out whether more than one
hunk would have been the result (and then tossed that result into the
trash). In C we instead count the number of resulting hunks (without
actually doing the work of splitting, but just counting the transitions
from non-context lines to context lines), and store that information
with the hunk, and we do that *while* parsing the diff in the first
place.
Another deviation: the built-in `git add -p` was designed with a single
strbuf holding the diff (and another one holding the colored diff, if
that one was asked for) in mind, and hunks essentially store just the
start and end offsets pointing into that strbuf. As a consequence, when
we split hunks, we now use a special mode where the hunk header is
generated dynamically, and only the rest of the hunk is stored using
such start/end offsets. This way, we also avoid the frequent
formatting/re-parsing of the hunk header of the Perl version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:58 +08:00
|
|
|
if (marker == '-' || marker == '+')
|
|
|
|
/*
|
|
|
|
* Should not happen; previous hunk did not end
|
|
|
|
* in a context line? Handle it anyway.
|
|
|
|
*/
|
|
|
|
hunk->splittable_into++;
|
|
|
|
|
2020-08-17 21:23:07 +08:00
|
|
|
ALLOC_GROW_BY(file_diff->hunk, file_diff->hunk_nr, 1,
|
2019-12-13 16:07:54 +08:00
|
|
|
file_diff->hunk_alloc);
|
|
|
|
hunk = file_diff->hunk + file_diff->hunk_nr - 1;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
|
|
|
|
hunk->start = p - plain->buf;
|
2019-12-13 16:07:50 +08:00
|
|
|
if (colored)
|
|
|
|
hunk->colored_start = colored_p - colored->buf;
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
|
2019-12-13 16:07:55 +08:00
|
|
|
if (deleted)
|
|
|
|
file_diff->deleted = 1;
|
|
|
|
else if (parse_hunk_header(s, hunk) < 0)
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
return -1;
|
built-in add -p: implement the hunk splitting feature
If this developer's workflow is any indication, then this is *the* most
useful feature of Git's interactive `add `command.
Note: once again, this is not a verbatim conversion from the Perl code
to C: the `hunk_splittable()` function, for example, essentially did all
the work of splitting the hunk, just to find out whether more than one
hunk would have been the result (and then tossed that result into the
trash). In C we instead count the number of resulting hunks (without
actually doing the work of splitting, but just counting the transitions
from non-context lines to context lines), and store that information
with the hunk, and we do that *while* parsing the diff in the first
place.
Another deviation: the built-in `git add -p` was designed with a single
strbuf holding the diff (and another one holding the colored diff, if
that one was asked for) in mind, and hunks essentially store just the
start and end offsets pointing into that strbuf. As a consequence, when
we split hunks, we now use a special mode where the hunk header is
generated dynamically, and only the rest of the hunk is stored using
such start/end offsets. This way, we also avoid the frequent
formatting/re-parsing of the hunk header of the Perl version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:58 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Start counting into how many hunks this one can be
|
|
|
|
* split
|
|
|
|
*/
|
|
|
|
marker = *p;
|
2020-09-09 21:58:52 +08:00
|
|
|
} else if (hunk == &file_diff->head &&
|
|
|
|
starts_with(p, "new file")) {
|
|
|
|
file_diff->added = 1;
|
2019-12-13 16:07:56 +08:00
|
|
|
} else if (hunk == &file_diff->head &&
|
|
|
|
skip_prefix(p, "old mode ", &mode_change) &&
|
|
|
|
is_octal(mode_change, eol - mode_change)) {
|
|
|
|
if (file_diff->mode_change)
|
|
|
|
BUG("double mode change?\n\n%.*s",
|
|
|
|
(int)(eol - plain->buf), plain->buf);
|
2020-08-17 21:23:07 +08:00
|
|
|
if (file_diff->hunk_nr)
|
2019-12-13 16:07:56 +08:00
|
|
|
BUG("mode change in the middle?\n\n%.*s",
|
|
|
|
(int)(eol - plain->buf), plain->buf);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Do *not* change `hunk`: the mode change pseudo-hunk
|
|
|
|
* is _part of_ the header "hunk".
|
|
|
|
*/
|
|
|
|
file_diff->mode_change = 1;
|
2020-08-17 21:23:07 +08:00
|
|
|
ALLOC_GROW_BY(file_diff->hunk, file_diff->hunk_nr, 1,
|
2019-12-13 16:07:56 +08:00
|
|
|
file_diff->hunk_alloc);
|
|
|
|
file_diff->hunk->start = p - plain->buf;
|
|
|
|
if (colored_p)
|
|
|
|
file_diff->hunk->colored_start =
|
|
|
|
colored_p - colored->buf;
|
|
|
|
} else if (hunk == &file_diff->head &&
|
|
|
|
skip_prefix(p, "new mode ", &mode_change) &&
|
|
|
|
is_octal(mode_change, eol - mode_change)) {
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Extend the "mode change" pseudo-hunk to include also
|
|
|
|
* the "new mode" line.
|
|
|
|
*/
|
|
|
|
if (!file_diff->mode_change)
|
|
|
|
BUG("'new mode' without 'old mode'?\n\n%.*s",
|
|
|
|
(int)(eol - plain->buf), plain->buf);
|
|
|
|
if (file_diff->hunk_nr != 1)
|
|
|
|
BUG("mode change in the middle?\n\n%.*s",
|
|
|
|
(int)(eol - plain->buf), plain->buf);
|
|
|
|
if (p - plain->buf != file_diff->hunk->end)
|
|
|
|
BUG("'new mode' does not immediately follow "
|
|
|
|
"'old mode'?\n\n%.*s",
|
|
|
|
(int)(eol - plain->buf), plain->buf);
|
2019-12-13 16:08:06 +08:00
|
|
|
} else if (hunk == &file_diff->head &&
|
|
|
|
starts_with(p, "Binary files "))
|
|
|
|
file_diff->binary = 1;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
|
2020-05-28 05:09:06 +08:00
|
|
|
if (!!file_diff->deleted + !!file_diff->added +
|
|
|
|
!!file_diff->mode_change > 1)
|
|
|
|
BUG("diff can only contain delete *or* add *or* a "
|
|
|
|
"mode change?!?\n%.*s",
|
2019-12-13 16:07:56 +08:00
|
|
|
(int)(eol - (plain->buf + file_diff->head.start)),
|
|
|
|
plain->buf + file_diff->head.start);
|
|
|
|
|
built-in add -p: implement the hunk splitting feature
If this developer's workflow is any indication, then this is *the* most
useful feature of Git's interactive `add `command.
Note: once again, this is not a verbatim conversion from the Perl code
to C: the `hunk_splittable()` function, for example, essentially did all
the work of splitting the hunk, just to find out whether more than one
hunk would have been the result (and then tossed that result into the
trash). In C we instead count the number of resulting hunks (without
actually doing the work of splitting, but just counting the transitions
from non-context lines to context lines), and store that information
with the hunk, and we do that *while* parsing the diff in the first
place.
Another deviation: the built-in `git add -p` was designed with a single
strbuf holding the diff (and another one holding the colored diff, if
that one was asked for) in mind, and hunks essentially store just the
start and end offsets pointing into that strbuf. As a consequence, when
we split hunks, we now use a special mode where the hunk header is
generated dynamically, and only the rest of the hunk is stored using
such start/end offsets. This way, we also avoid the frequent
formatting/re-parsing of the hunk header of the Perl version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:58 +08:00
|
|
|
if ((marker == '-' || marker == '+') && *p == ' ')
|
|
|
|
hunk->splittable_into++;
|
|
|
|
if (marker && *p != '\\')
|
|
|
|
marker = *p;
|
|
|
|
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
p = eol == pend ? pend : eol + 1;
|
|
|
|
hunk->end = p - plain->buf;
|
2019-12-13 16:07:50 +08:00
|
|
|
|
|
|
|
if (colored) {
|
|
|
|
char *colored_eol = memchr(colored_p, '\n',
|
|
|
|
colored_pend - colored_p);
|
|
|
|
if (colored_eol)
|
|
|
|
colored_p = colored_eol + 1;
|
2020-01-15 02:43:45 +08:00
|
|
|
else if (p != pend)
|
2022-09-01 23:42:17 +08:00
|
|
|
/* non-colored has more lines? */
|
|
|
|
goto mismatched_output;
|
|
|
|
else if (colored_p == colored_pend)
|
|
|
|
/* last line has no matching colored one? */
|
2020-01-15 02:43:45 +08:00
|
|
|
goto mismatched_output;
|
2019-12-13 16:07:50 +08:00
|
|
|
else
|
|
|
|
colored_p = colored_pend;
|
|
|
|
|
|
|
|
hunk->colored_end = colored_p - colored->buf;
|
|
|
|
}
|
2019-12-13 16:07:56 +08:00
|
|
|
|
|
|
|
if (mode_change) {
|
|
|
|
if (file_diff->hunk_nr != 1)
|
|
|
|
BUG("mode change in hunk #%d???",
|
|
|
|
(int)file_diff->hunk_nr);
|
|
|
|
/* Adjust the end of the "mode change" pseudo-hunk */
|
|
|
|
file_diff->hunk->end = hunk->end;
|
|
|
|
if (colored)
|
|
|
|
file_diff->hunk->colored_end = hunk->colored_end;
|
|
|
|
}
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
}
|
2022-01-11 19:12:10 +08:00
|
|
|
complete_file(marker, hunk);
|
built-in add -p: implement the hunk splitting feature
If this developer's workflow is any indication, then this is *the* most
useful feature of Git's interactive `add `command.
Note: once again, this is not a verbatim conversion from the Perl code
to C: the `hunk_splittable()` function, for example, essentially did all
the work of splitting the hunk, just to find out whether more than one
hunk would have been the result (and then tossed that result into the
trash). In C we instead count the number of resulting hunks (without
actually doing the work of splitting, but just counting the transitions
from non-context lines to context lines), and store that information
with the hunk, and we do that *while* parsing the diff in the first
place.
Another deviation: the built-in `git add -p` was designed with a single
strbuf holding the diff (and another one holding the colored diff, if
that one was asked for) in mind, and hunks essentially store just the
start and end offsets pointing into that strbuf. As a consequence, when
we split hunks, we now use a special mode where the hunk header is
generated dynamically, and only the rest of the hunk is stored using
such start/end offsets. This way, we also avoid the frequent
formatting/re-parsing of the hunk header of the Perl version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:58 +08:00
|
|
|
|
2020-01-15 02:43:45 +08:00
|
|
|
/* non-colored shorter than colored? */
|
|
|
|
if (colored_p != colored_pend) {
|
|
|
|
mismatched_output:
|
|
|
|
error(_("mismatched output from interactive.diffFilter"));
|
|
|
|
advise(_("Your filter must maintain a one-to-one correspondence\n"
|
|
|
|
"between its input and output lines."));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
built-in add -p: implement the hunk splitting feature
If this developer's workflow is any indication, then this is *the* most
useful feature of Git's interactive `add `command.
Note: once again, this is not a verbatim conversion from the Perl code
to C: the `hunk_splittable()` function, for example, essentially did all
the work of splitting the hunk, just to find out whether more than one
hunk would have been the result (and then tossed that result into the
trash). In C we instead count the number of resulting hunks (without
actually doing the work of splitting, but just counting the transitions
from non-context lines to context lines), and store that information
with the hunk, and we do that *while* parsing the diff in the first
place.
Another deviation: the built-in `git add -p` was designed with a single
strbuf holding the diff (and another one holding the colored diff, if
that one was asked for) in mind, and hunks essentially store just the
start and end offsets pointing into that strbuf. As a consequence, when
we split hunks, we now use a special mode where the hunk header is
generated dynamically, and only the rest of the hunk is stored using
such start/end offsets. This way, we also avoid the frequent
formatting/re-parsing of the hunk header of the Perl version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:58 +08:00
|
|
|
static size_t find_next_line(struct strbuf *sb, size_t offset)
|
|
|
|
{
|
|
|
|
char *eol;
|
|
|
|
|
|
|
|
if (offset >= sb->len)
|
|
|
|
BUG("looking for next line beyond buffer (%d >= %d)\n%s",
|
|
|
|
(int)offset, (int)sb->len, sb->buf);
|
|
|
|
|
|
|
|
eol = memchr(sb->buf + offset, '\n', sb->len - offset);
|
|
|
|
if (!eol)
|
|
|
|
return sb->len;
|
|
|
|
return eol - sb->buf + 1;
|
|
|
|
}
|
|
|
|
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
static void render_hunk(struct add_p_state *s, struct hunk *hunk,
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
ssize_t delta, int colored, struct strbuf *out)
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
{
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
struct hunk_header *header = &hunk->header;
|
|
|
|
|
|
|
|
if (hunk->header.old_offset != 0 || hunk->header.new_offset != 0) {
|
|
|
|
/*
|
|
|
|
* Generate the hunk header dynamically, except for special
|
|
|
|
* hunks (such as the diff header).
|
|
|
|
*/
|
|
|
|
const char *p;
|
|
|
|
size_t len;
|
|
|
|
unsigned long old_offset = header->old_offset;
|
|
|
|
unsigned long new_offset = header->new_offset;
|
|
|
|
|
|
|
|
if (!colored) {
|
|
|
|
p = s->plain.buf + header->extra_start;
|
|
|
|
len = header->extra_end - header->extra_start;
|
2022-09-01 23:42:18 +08:00
|
|
|
} else if (header->suppress_colored_line_range) {
|
|
|
|
strbuf_add(out,
|
|
|
|
s->colored.buf + header->colored_extra_start,
|
|
|
|
header->colored_extra_end -
|
|
|
|
header->colored_extra_start);
|
|
|
|
|
|
|
|
strbuf_add(out, s->colored.buf + hunk->colored_start,
|
|
|
|
hunk->colored_end - hunk->colored_start);
|
|
|
|
return;
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
} else {
|
|
|
|
strbuf_addstr(out, s->s.fraginfo_color);
|
|
|
|
p = s->colored.buf + header->colored_extra_start;
|
|
|
|
len = header->colored_extra_end
|
|
|
|
- header->colored_extra_start;
|
|
|
|
}
|
|
|
|
|
2019-12-22 05:57:10 +08:00
|
|
|
if (s->mode->is_reverse)
|
|
|
|
old_offset -= delta;
|
|
|
|
else
|
|
|
|
new_offset += delta;
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
|
2020-11-11 20:28:16 +08:00
|
|
|
strbuf_addf(out, "@@ -%lu", old_offset);
|
|
|
|
if (header->old_count != 1)
|
|
|
|
strbuf_addf(out, ",%lu", header->old_count);
|
|
|
|
strbuf_addf(out, " +%lu", new_offset);
|
|
|
|
if (header->new_count != 1)
|
|
|
|
strbuf_addf(out, ",%lu", header->new_count);
|
|
|
|
strbuf_addstr(out, " @@");
|
|
|
|
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
if (len)
|
|
|
|
strbuf_add(out, p, len);
|
|
|
|
else if (colored)
|
2020-11-11 20:28:17 +08:00
|
|
|
strbuf_addf(out, "%s\n", s->s.reset_color);
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
else
|
|
|
|
strbuf_addch(out, '\n');
|
|
|
|
}
|
|
|
|
|
2019-12-13 16:07:50 +08:00
|
|
|
if (colored)
|
|
|
|
strbuf_add(out, s->colored.buf + hunk->colored_start,
|
|
|
|
hunk->colored_end - hunk->colored_start);
|
|
|
|
else
|
|
|
|
strbuf_add(out, s->plain.buf + hunk->start,
|
|
|
|
hunk->end - hunk->start);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
}
|
|
|
|
|
2019-12-13 16:07:56 +08:00
|
|
|
static void render_diff_header(struct add_p_state *s,
|
|
|
|
struct file_diff *file_diff, int colored,
|
|
|
|
struct strbuf *out)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If there was a mode change, the first hunk is a pseudo hunk that
|
|
|
|
* corresponds to the mode line in the header. If the user did not want
|
|
|
|
* to stage that "hunk", we actually have to cut it out from the header.
|
|
|
|
*/
|
|
|
|
int skip_mode_change =
|
|
|
|
file_diff->mode_change && file_diff->hunk->use != USE_HUNK;
|
|
|
|
struct hunk *head = &file_diff->head, *first = file_diff->hunk;
|
|
|
|
|
|
|
|
if (!skip_mode_change) {
|
|
|
|
render_hunk(s, head, 0, colored, out);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (colored) {
|
|
|
|
const char *p = s->colored.buf;
|
|
|
|
|
|
|
|
strbuf_add(out, p + head->colored_start,
|
|
|
|
first->colored_start - head->colored_start);
|
|
|
|
strbuf_add(out, p + first->colored_end,
|
|
|
|
head->colored_end - first->colored_end);
|
|
|
|
} else {
|
|
|
|
const char *p = s->plain.buf;
|
|
|
|
|
|
|
|
strbuf_add(out, p + head->start, first->start - head->start);
|
|
|
|
strbuf_add(out, p + first->end, head->end - first->end);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-12-13 16:07:59 +08:00
|
|
|
/* Coalesce hunks again that were split */
|
|
|
|
static int merge_hunks(struct add_p_state *s, struct file_diff *file_diff,
|
2019-12-13 16:08:01 +08:00
|
|
|
size_t *hunk_index, int use_all, struct hunk *merged)
|
2019-12-13 16:07:59 +08:00
|
|
|
{
|
2019-12-13 16:08:01 +08:00
|
|
|
size_t i = *hunk_index, delta;
|
2019-12-13 16:07:59 +08:00
|
|
|
struct hunk *hunk = file_diff->hunk + i;
|
|
|
|
/* `header` corresponds to the merged hunk */
|
|
|
|
struct hunk_header *header = &merged->header, *next;
|
|
|
|
|
2019-12-13 16:08:01 +08:00
|
|
|
if (!use_all && hunk->use != USE_HUNK)
|
2019-12-13 16:07:59 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
*merged = *hunk;
|
|
|
|
/* We simply skip the colored part (if any) when merging hunks */
|
|
|
|
merged->colored_start = merged->colored_end = 0;
|
|
|
|
|
|
|
|
for (; i + 1 < file_diff->hunk_nr; i++) {
|
|
|
|
hunk++;
|
|
|
|
next = &hunk->header;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Stop merging hunks when:
|
|
|
|
*
|
|
|
|
* - the hunk is not selected for use, or
|
|
|
|
* - the hunk does not overlap with the already-merged hunk(s)
|
|
|
|
*/
|
2019-12-13 16:08:01 +08:00
|
|
|
if ((!use_all && hunk->use != USE_HUNK) ||
|
|
|
|
header->new_offset >= next->new_offset + merged->delta ||
|
|
|
|
header->new_offset + header->new_count
|
|
|
|
< next->new_offset + merged->delta)
|
2019-12-13 16:07:59 +08:00
|
|
|
break;
|
|
|
|
|
2019-12-13 16:08:01 +08:00
|
|
|
/*
|
|
|
|
* If the hunks were not edited, and overlap, we can simply
|
|
|
|
* extend the line range.
|
|
|
|
*/
|
|
|
|
if (merged->start < hunk->start && merged->end > hunk->start) {
|
|
|
|
merged->end = hunk->end;
|
|
|
|
merged->colored_end = hunk->colored_end;
|
|
|
|
delta = 0;
|
|
|
|
} else {
|
|
|
|
const char *plain = s->plain.buf;
|
|
|
|
size_t overlapping_line_count = header->new_offset
|
|
|
|
+ header->new_count - merged->delta
|
|
|
|
- next->new_offset;
|
|
|
|
size_t overlap_end = hunk->start;
|
|
|
|
size_t overlap_start = overlap_end;
|
|
|
|
size_t overlap_next, len, j;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* One of the hunks was edited: the modified hunk was
|
|
|
|
* appended to the strbuf `s->plain`.
|
|
|
|
*
|
|
|
|
* Let's ensure that at least the last context line of
|
|
|
|
* the first hunk overlaps with the corresponding line
|
|
|
|
* of the second hunk, and then merge.
|
|
|
|
*/
|
|
|
|
for (j = 0; j < overlapping_line_count; j++) {
|
|
|
|
overlap_next = find_next_line(&s->plain,
|
|
|
|
overlap_end);
|
|
|
|
|
|
|
|
if (overlap_next > hunk->end)
|
|
|
|
BUG("failed to find %d context lines "
|
|
|
|
"in:\n%.*s",
|
|
|
|
(int)overlapping_line_count,
|
|
|
|
(int)(hunk->end - hunk->start),
|
|
|
|
plain + hunk->start);
|
|
|
|
|
|
|
|
if (plain[overlap_end] != ' ')
|
|
|
|
return error(_("expected context line "
|
|
|
|
"#%d in\n%.*s"),
|
|
|
|
(int)(j + 1),
|
|
|
|
(int)(hunk->end
|
|
|
|
- hunk->start),
|
|
|
|
plain + hunk->start);
|
|
|
|
|
|
|
|
overlap_start = overlap_end;
|
|
|
|
overlap_end = overlap_next;
|
|
|
|
}
|
|
|
|
len = overlap_end - overlap_start;
|
|
|
|
|
|
|
|
if (len > merged->end - merged->start ||
|
|
|
|
memcmp(plain + merged->end - len,
|
|
|
|
plain + overlap_start, len))
|
|
|
|
return error(_("hunks do not overlap:\n%.*s\n"
|
|
|
|
"\tdoes not end with:\n%.*s"),
|
|
|
|
(int)(merged->end - merged->start),
|
|
|
|
plain + merged->start,
|
|
|
|
(int)len, plain + overlap_start);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since the start-end ranges are not adjacent, we
|
|
|
|
* cannot simply take the union of the ranges. To
|
|
|
|
* address that, we temporarily append the union of the
|
|
|
|
* lines to the `plain` strbuf.
|
|
|
|
*/
|
|
|
|
if (merged->end != s->plain.len) {
|
|
|
|
size_t start = s->plain.len;
|
|
|
|
|
|
|
|
strbuf_add(&s->plain, plain + merged->start,
|
|
|
|
merged->end - merged->start);
|
|
|
|
plain = s->plain.buf;
|
|
|
|
merged->start = start;
|
|
|
|
merged->end = s->plain.len;
|
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_add(&s->plain,
|
|
|
|
plain + overlap_end,
|
|
|
|
hunk->end - overlap_end);
|
|
|
|
merged->end = s->plain.len;
|
|
|
|
merged->splittable_into += hunk->splittable_into;
|
|
|
|
delta = merged->delta;
|
|
|
|
merged->delta += hunk->delta;
|
|
|
|
}
|
2019-12-13 16:07:59 +08:00
|
|
|
|
|
|
|
header->old_count = next->old_offset + next->old_count
|
|
|
|
- header->old_offset;
|
2019-12-13 16:08:01 +08:00
|
|
|
header->new_count = next->new_offset + delta
|
|
|
|
+ next->new_count - header->new_offset;
|
2019-12-13 16:07:59 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (i == *hunk_index)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
*hunk_index = i;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2019-12-13 16:07:54 +08:00
|
|
|
static void reassemble_patch(struct add_p_state *s,
|
2019-12-13 16:08:01 +08:00
|
|
|
struct file_diff *file_diff, int use_all,
|
|
|
|
struct strbuf *out)
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
{
|
|
|
|
struct hunk *hunk;
|
2019-12-13 16:08:01 +08:00
|
|
|
size_t save_len = s->plain.len, i;
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
ssize_t delta = 0;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
|
2019-12-13 16:07:56 +08:00
|
|
|
render_diff_header(s, file_diff, 0, out);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
|
2019-12-13 16:07:56 +08:00
|
|
|
for (i = file_diff->mode_change; i < file_diff->hunk_nr; i++) {
|
2019-12-13 16:07:59 +08:00
|
|
|
struct hunk merged = { 0 };
|
|
|
|
|
2019-12-13 16:07:54 +08:00
|
|
|
hunk = file_diff->hunk + i;
|
2019-12-13 16:08:01 +08:00
|
|
|
if (!use_all && hunk->use != USE_HUNK)
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
delta += hunk->header.old_count
|
|
|
|
- hunk->header.new_count;
|
2019-12-13 16:07:59 +08:00
|
|
|
else {
|
|
|
|
/* merge overlapping hunks into a temporary hunk */
|
2019-12-13 16:08:01 +08:00
|
|
|
if (merge_hunks(s, file_diff, &i, use_all, &merged))
|
2019-12-13 16:07:59 +08:00
|
|
|
hunk = &merged;
|
|
|
|
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
render_hunk(s, hunk, delta, 0, out);
|
2019-12-13 16:08:01 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* In case `merge_hunks()` used `plain` as a scratch
|
|
|
|
* pad (this happens when an edited hunk had to be
|
|
|
|
* coalesced with another hunk).
|
|
|
|
*/
|
|
|
|
strbuf_setlen(&s->plain, save_len);
|
|
|
|
|
|
|
|
delta += hunk->delta;
|
2019-12-13 16:07:59 +08:00
|
|
|
}
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
built-in add -p: implement the hunk splitting feature
If this developer's workflow is any indication, then this is *the* most
useful feature of Git's interactive `add `command.
Note: once again, this is not a verbatim conversion from the Perl code
to C: the `hunk_splittable()` function, for example, essentially did all
the work of splitting the hunk, just to find out whether more than one
hunk would have been the result (and then tossed that result into the
trash). In C we instead count the number of resulting hunks (without
actually doing the work of splitting, but just counting the transitions
from non-context lines to context lines), and store that information
with the hunk, and we do that *while* parsing the diff in the first
place.
Another deviation: the built-in `git add -p` was designed with a single
strbuf holding the diff (and another one holding the colored diff, if
that one was asked for) in mind, and hunks essentially store just the
start and end offsets pointing into that strbuf. As a consequence, when
we split hunks, we now use a special mode where the hunk header is
generated dynamically, and only the rest of the hunk is stored using
such start/end offsets. This way, we also avoid the frequent
formatting/re-parsing of the hunk header of the Perl version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:58 +08:00
|
|
|
static int split_hunk(struct add_p_state *s, struct file_diff *file_diff,
|
|
|
|
size_t hunk_index)
|
|
|
|
{
|
|
|
|
int colored = !!s->colored.len, first = 1;
|
|
|
|
struct hunk *hunk = file_diff->hunk + hunk_index;
|
|
|
|
size_t splittable_into;
|
|
|
|
size_t end, colored_end, current, colored_current = 0, context_line_count;
|
|
|
|
struct hunk_header remaining, *header;
|
|
|
|
char marker, ch;
|
|
|
|
|
|
|
|
if (hunk_index >= file_diff->hunk_nr)
|
|
|
|
BUG("invalid hunk index: %d (must be >= 0 and < %d)",
|
|
|
|
(int)hunk_index, (int)file_diff->hunk_nr);
|
|
|
|
|
|
|
|
if (hunk->splittable_into < 2)
|
|
|
|
return 0;
|
|
|
|
splittable_into = hunk->splittable_into;
|
|
|
|
|
|
|
|
end = hunk->end;
|
|
|
|
colored_end = hunk->colored_end;
|
|
|
|
|
|
|
|
remaining = hunk->header;
|
|
|
|
|
|
|
|
file_diff->hunk_nr += splittable_into - 1;
|
|
|
|
ALLOC_GROW(file_diff->hunk, file_diff->hunk_nr, file_diff->hunk_alloc);
|
|
|
|
if (hunk_index + splittable_into < file_diff->hunk_nr)
|
|
|
|
memmove(file_diff->hunk + hunk_index + splittable_into,
|
|
|
|
file_diff->hunk + hunk_index + 1,
|
|
|
|
(file_diff->hunk_nr - hunk_index - splittable_into)
|
|
|
|
* sizeof(*hunk));
|
|
|
|
hunk = file_diff->hunk + hunk_index;
|
|
|
|
hunk->splittable_into = 1;
|
|
|
|
memset(hunk + 1, 0, (splittable_into - 1) * sizeof(*hunk));
|
|
|
|
|
|
|
|
header = &hunk->header;
|
|
|
|
header->old_count = header->new_count = 0;
|
|
|
|
|
|
|
|
current = hunk->start;
|
|
|
|
if (colored)
|
|
|
|
colored_current = hunk->colored_start;
|
|
|
|
marker = '\0';
|
|
|
|
context_line_count = 0;
|
|
|
|
|
|
|
|
while (splittable_into > 1) {
|
|
|
|
ch = s->plain.buf[current];
|
|
|
|
|
|
|
|
if (!ch)
|
|
|
|
BUG("buffer overrun while splitting hunks");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Is this the first context line after a chain of +/- lines?
|
|
|
|
* Then record the start of the next split hunk.
|
|
|
|
*/
|
|
|
|
if ((marker == '-' || marker == '+') && ch == ' ') {
|
|
|
|
first = 0;
|
|
|
|
hunk[1].start = current;
|
|
|
|
if (colored)
|
|
|
|
hunk[1].colored_start = colored_current;
|
|
|
|
context_line_count = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Was the previous line a +/- one? Alternatively, is this the
|
|
|
|
* first line (and not a +/- one)?
|
|
|
|
*
|
|
|
|
* Then just increment the appropriate counter and continue
|
|
|
|
* with the next line.
|
|
|
|
*/
|
|
|
|
if (marker != ' ' || (ch != '-' && ch != '+')) {
|
|
|
|
next_hunk_line:
|
|
|
|
/* Comment lines are attached to the previous line */
|
|
|
|
if (ch == '\\')
|
|
|
|
ch = marker ? marker : ' ';
|
|
|
|
|
|
|
|
/* current hunk not done yet */
|
|
|
|
if (ch == ' ')
|
|
|
|
context_line_count++;
|
|
|
|
else if (ch == '-')
|
|
|
|
header->old_count++;
|
|
|
|
else if (ch == '+')
|
|
|
|
header->new_count++;
|
|
|
|
else
|
|
|
|
BUG("unhandled diff marker: '%c'", ch);
|
|
|
|
marker = ch;
|
|
|
|
current = find_next_line(&s->plain, current);
|
|
|
|
if (colored)
|
|
|
|
colored_current =
|
|
|
|
find_next_line(&s->colored,
|
|
|
|
colored_current);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We got us the start of a new hunk!
|
|
|
|
*
|
|
|
|
* This is a context line, so it is shared with the previous
|
|
|
|
* hunk, if any.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (first) {
|
|
|
|
if (header->old_count || header->new_count)
|
|
|
|
BUG("counts are off: %d/%d",
|
|
|
|
(int)header->old_count,
|
|
|
|
(int)header->new_count);
|
|
|
|
|
|
|
|
header->old_count = context_line_count;
|
|
|
|
header->new_count = context_line_count;
|
|
|
|
context_line_count = 0;
|
|
|
|
first = 0;
|
|
|
|
goto next_hunk_line;
|
|
|
|
}
|
|
|
|
|
|
|
|
remaining.old_offset += header->old_count;
|
|
|
|
remaining.old_count -= header->old_count;
|
|
|
|
remaining.new_offset += header->new_count;
|
|
|
|
remaining.new_count -= header->new_count;
|
|
|
|
|
|
|
|
/* initialize next hunk header's offsets */
|
|
|
|
hunk[1].header.old_offset =
|
|
|
|
header->old_offset + header->old_count;
|
|
|
|
hunk[1].header.new_offset =
|
|
|
|
header->new_offset + header->new_count;
|
|
|
|
|
|
|
|
/* add one split hunk */
|
|
|
|
header->old_count += context_line_count;
|
|
|
|
header->new_count += context_line_count;
|
|
|
|
|
|
|
|
hunk->end = current;
|
|
|
|
if (colored)
|
|
|
|
hunk->colored_end = colored_current;
|
|
|
|
|
|
|
|
hunk++;
|
|
|
|
hunk->splittable_into = 1;
|
|
|
|
hunk->use = hunk[-1].use;
|
|
|
|
header = &hunk->header;
|
|
|
|
|
|
|
|
header->old_count = header->new_count = context_line_count;
|
|
|
|
context_line_count = 0;
|
|
|
|
|
|
|
|
splittable_into--;
|
|
|
|
marker = ch;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* last hunk simply gets the rest */
|
|
|
|
if (header->old_offset != remaining.old_offset)
|
|
|
|
BUG("miscounted old_offset: %lu != %lu",
|
|
|
|
header->old_offset, remaining.old_offset);
|
|
|
|
if (header->new_offset != remaining.new_offset)
|
|
|
|
BUG("miscounted new_offset: %lu != %lu",
|
|
|
|
header->new_offset, remaining.new_offset);
|
|
|
|
header->old_count = remaining.old_count;
|
|
|
|
header->new_count = remaining.new_count;
|
|
|
|
hunk->end = end;
|
|
|
|
if (colored)
|
|
|
|
hunk->colored_end = colored_end;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-12-13 16:08:01 +08:00
|
|
|
static void recolor_hunk(struct add_p_state *s, struct hunk *hunk)
|
|
|
|
{
|
|
|
|
const char *plain = s->plain.buf;
|
|
|
|
size_t current, eol, next;
|
|
|
|
|
|
|
|
if (!s->colored.len)
|
|
|
|
return;
|
|
|
|
|
|
|
|
hunk->colored_start = s->colored.len;
|
|
|
|
for (current = hunk->start; current < hunk->end; ) {
|
|
|
|
for (eol = current; eol < hunk->end; eol++)
|
|
|
|
if (plain[eol] == '\n')
|
|
|
|
break;
|
|
|
|
next = eol + (eol < hunk->end);
|
|
|
|
if (eol > current && plain[eol - 1] == '\r')
|
|
|
|
eol--;
|
|
|
|
|
|
|
|
strbuf_addstr(&s->colored,
|
|
|
|
plain[current] == '-' ?
|
|
|
|
s->s.file_old_color :
|
|
|
|
plain[current] == '+' ?
|
|
|
|
s->s.file_new_color :
|
|
|
|
s->s.context_color);
|
|
|
|
strbuf_add(&s->colored, plain + current, eol - current);
|
2020-11-11 20:28:17 +08:00
|
|
|
strbuf_addstr(&s->colored, s->s.reset_color);
|
2019-12-13 16:08:01 +08:00
|
|
|
if (next > eol)
|
|
|
|
strbuf_add(&s->colored, plain + eol, next - eol);
|
|
|
|
current = next;
|
|
|
|
}
|
|
|
|
hunk->colored_end = s->colored.len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int edit_hunk_manually(struct add_p_state *s, struct hunk *hunk)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
strbuf_reset(&s->buf);
|
2024-03-12 17:17:29 +08:00
|
|
|
strbuf_commented_addf(&s->buf, comment_line_str,
|
2023-06-07 03:48:43 +08:00
|
|
|
_("Manual hunk edit mode -- see bottom for "
|
|
|
|
"a quick guide.\n"));
|
2019-12-13 16:08:01 +08:00
|
|
|
render_hunk(s, hunk, 0, 0, &s->buf);
|
2024-03-12 17:17:29 +08:00
|
|
|
strbuf_commented_addf(&s->buf, comment_line_str,
|
2019-12-13 16:08:01 +08:00
|
|
|
_("---\n"
|
|
|
|
"To remove '%c' lines, make them ' ' lines "
|
|
|
|
"(context).\n"
|
|
|
|
"To remove '%c' lines, delete them.\n"
|
2024-03-12 17:17:34 +08:00
|
|
|
"Lines starting with %s will be removed.\n"),
|
2019-12-22 05:57:10 +08:00
|
|
|
s->mode->is_reverse ? '+' : '-',
|
|
|
|
s->mode->is_reverse ? '-' : '+',
|
2024-03-12 17:17:34 +08:00
|
|
|
comment_line_str);
|
2024-03-12 17:17:29 +08:00
|
|
|
strbuf_commented_addf(&s->buf, comment_line_str, "%s",
|
2023-06-07 03:48:43 +08:00
|
|
|
_(s->mode->edit_hunk_hint));
|
2019-12-13 16:08:01 +08:00
|
|
|
/*
|
|
|
|
* TRANSLATORS: 'it' refers to the patch mentioned in the previous
|
|
|
|
* messages.
|
|
|
|
*/
|
2024-03-12 17:17:29 +08:00
|
|
|
strbuf_commented_addf(&s->buf, comment_line_str,
|
2019-12-13 16:08:01 +08:00
|
|
|
_("If it does not apply cleanly, you will be "
|
|
|
|
"given an opportunity to\n"
|
|
|
|
"edit again. If all lines of the hunk are "
|
|
|
|
"removed, then the edit is\n"
|
|
|
|
"aborted and the hunk is left unchanged.\n"));
|
|
|
|
|
|
|
|
if (strbuf_edit_interactively(&s->buf, "addp-hunk-edit.diff", NULL) < 0)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
/* strip out commented lines */
|
|
|
|
hunk->start = s->plain.len;
|
|
|
|
for (i = 0; i < s->buf.len; ) {
|
|
|
|
size_t next = find_next_line(&s->buf, i);
|
|
|
|
|
2024-03-12 17:17:37 +08:00
|
|
|
if (!starts_with(s->buf.buf + i, comment_line_str))
|
2019-12-13 16:08:01 +08:00
|
|
|
strbuf_add(&s->plain, s->buf.buf + i, next - i);
|
|
|
|
i = next;
|
|
|
|
}
|
|
|
|
|
|
|
|
hunk->end = s->plain.len;
|
|
|
|
if (hunk->end == hunk->start)
|
|
|
|
/* The user aborted editing by deleting everything */
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
recolor_hunk(s, hunk);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the hunk header is intact, parse it, otherwise simply use the
|
|
|
|
* hunk header prior to editing (which will adjust `hunk->start` to
|
|
|
|
* skip the hunk header).
|
|
|
|
*/
|
|
|
|
if (s->plain.buf[hunk->start] == '@' &&
|
|
|
|
parse_hunk_header(s, hunk) < 0)
|
|
|
|
return error(_("could not parse hunk header"));
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t recount_edited_hunk(struct add_p_state *s, struct hunk *hunk,
|
|
|
|
size_t orig_old_count, size_t orig_new_count)
|
|
|
|
{
|
|
|
|
struct hunk_header *header = &hunk->header;
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
header->old_count = header->new_count = 0;
|
|
|
|
for (i = hunk->start; i < hunk->end; ) {
|
|
|
|
switch (s->plain.buf[i]) {
|
|
|
|
case '-':
|
|
|
|
header->old_count++;
|
|
|
|
break;
|
|
|
|
case '+':
|
|
|
|
header->new_count++;
|
|
|
|
break;
|
|
|
|
case ' ': case '\r': case '\n':
|
|
|
|
header->old_count++;
|
|
|
|
header->new_count++;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
i = find_next_line(&s->plain, i);
|
|
|
|
}
|
|
|
|
|
|
|
|
return orig_old_count - orig_new_count
|
|
|
|
- header->old_count + header->new_count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int run_apply_check(struct add_p_state *s,
|
|
|
|
struct file_diff *file_diff)
|
|
|
|
{
|
|
|
|
struct child_process cp = CHILD_PROCESS_INIT;
|
|
|
|
|
|
|
|
strbuf_reset(&s->buf);
|
|
|
|
reassemble_patch(s, file_diff, 1, &s->buf);
|
|
|
|
|
|
|
|
setup_child_process(s, &cp,
|
2019-12-22 05:57:10 +08:00
|
|
|
"apply", "--check", NULL);
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_pushv(&cp.args, s->mode->apply_check_args);
|
2019-12-13 16:08:01 +08:00
|
|
|
if (pipe_command(&cp, s->buf.buf, s->buf.len, NULL, 0, NULL, 0))
|
|
|
|
return error(_("'git apply --cached' failed"));
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-01-15 02:43:50 +08:00
|
|
|
static int read_single_character(struct add_p_state *s)
|
|
|
|
{
|
|
|
|
if (s->s.use_single_key) {
|
|
|
|
int res = read_key_without_echo(&s->answer);
|
|
|
|
printf("%s\n", res == EOF ? "" : s->answer.buf);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2020-04-10 19:27:50 +08:00
|
|
|
if (git_read_line_interactively(&s->answer) == EOF)
|
2020-01-15 02:43:50 +08:00
|
|
|
return EOF;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-12-13 16:08:01 +08:00
|
|
|
static int prompt_yesno(struct add_p_state *s, const char *prompt)
|
|
|
|
{
|
|
|
|
for (;;) {
|
|
|
|
color_fprintf(stdout, s->s.prompt_color, "%s", _(prompt));
|
|
|
|
fflush(stdout);
|
2020-01-15 02:43:50 +08:00
|
|
|
if (read_single_character(s) == EOF)
|
2019-12-13 16:08:01 +08:00
|
|
|
return -1;
|
add-patch: enforce only one-letter response to prompts
In a "git add -p" session, especially when we are not using the
single-key mode, we may see 'qa' as a response to a prompt
(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
and then just do the 'q' thing (i.e. quit the session), ignoring
everything other than the first byte.
If 'q' and 'a' are next to each other on the user's keyboard, there
is a plausible chance that we see 'qa' when the user who wanted to
say 'a' fat-fingered and we ended up doing the 'q' thing instead.
As we didn't think of a good reason during the review discussion why
we want to accept excess letters only to ignore them, it appears to
be a safe change to simply reject input that is longer than just one
byte.
The two exceptions are the 'g' command that takes a hunk number, and
the '/' command that takes a regular expression. They have to be
accompanied by their operands (this makes me wonder how users who
set the interactive.singlekey configuration feed these operands---it
turns out that we notice there is no operand and give them another
chance to type the operand separately, without using single key
input this time), so we accept a string that is more than one byte
long.
Keep the "use only the first byte, downcased" behaviour when we ask
yes/no question, though. Neither on Qwerty or on Dvorak, 'y' and
'n' are not close to each other.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-05-23 05:45:48 +08:00
|
|
|
/* do not limit to 1-byte input to allow 'no' etc. */
|
2019-12-13 16:08:01 +08:00
|
|
|
switch (tolower(s->answer.buf[0])) {
|
|
|
|
case 'n': return 0;
|
|
|
|
case 'y': return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int edit_hunk_loop(struct add_p_state *s,
|
|
|
|
struct file_diff *file_diff, struct hunk *hunk)
|
|
|
|
{
|
|
|
|
size_t plain_len = s->plain.len, colored_len = s->colored.len;
|
|
|
|
struct hunk backup;
|
|
|
|
|
|
|
|
backup = *hunk;
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
int res = edit_hunk_manually(s, hunk);
|
|
|
|
if (res == 0) {
|
2020-07-29 11:33:28 +08:00
|
|
|
/* abandoned */
|
2019-12-13 16:08:01 +08:00
|
|
|
*hunk = backup;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (res > 0) {
|
|
|
|
hunk->delta +=
|
|
|
|
recount_edited_hunk(s, hunk,
|
|
|
|
backup.header.old_count,
|
|
|
|
backup.header.new_count);
|
|
|
|
if (!run_apply_check(s, file_diff))
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Drop edits (they were appended to s->plain) */
|
|
|
|
strbuf_setlen(&s->plain, plain_len);
|
|
|
|
strbuf_setlen(&s->colored, colored_len);
|
|
|
|
*hunk = backup;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* TRANSLATORS: do not translate [y/n]
|
|
|
|
* The program will only accept that input at this point.
|
|
|
|
* Consider translating (saying "no" discards!) as
|
|
|
|
* (saying "n" for "no" discards!) if the translation
|
|
|
|
* of the word "no" does not start with n.
|
|
|
|
*/
|
|
|
|
res = prompt_yesno(s, _("Your edited hunk does not apply. "
|
|
|
|
"Edit again (saying \"no\" discards!) "
|
|
|
|
"[y/n]? "));
|
|
|
|
if (res < 1)
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-12-22 05:57:14 +08:00
|
|
|
static int apply_for_checkout(struct add_p_state *s, struct strbuf *diff,
|
|
|
|
int is_reverse)
|
|
|
|
{
|
|
|
|
const char *reverse = is_reverse ? "-R" : NULL;
|
|
|
|
struct child_process check_index = CHILD_PROCESS_INIT;
|
|
|
|
struct child_process check_worktree = CHILD_PROCESS_INIT;
|
|
|
|
struct child_process apply_index = CHILD_PROCESS_INIT;
|
|
|
|
struct child_process apply_worktree = CHILD_PROCESS_INIT;
|
|
|
|
int applies_index, applies_worktree;
|
|
|
|
|
|
|
|
setup_child_process(s, &check_index,
|
|
|
|
"apply", "--cached", "--check", reverse, NULL);
|
|
|
|
applies_index = !pipe_command(&check_index, diff->buf, diff->len,
|
|
|
|
NULL, 0, NULL, 0);
|
|
|
|
|
|
|
|
setup_child_process(s, &check_worktree,
|
|
|
|
"apply", "--check", reverse, NULL);
|
|
|
|
applies_worktree = !pipe_command(&check_worktree, diff->buf, diff->len,
|
|
|
|
NULL, 0, NULL, 0);
|
|
|
|
|
|
|
|
if (applies_worktree && applies_index) {
|
|
|
|
setup_child_process(s, &apply_index,
|
|
|
|
"apply", "--cached", reverse, NULL);
|
|
|
|
pipe_command(&apply_index, diff->buf, diff->len,
|
|
|
|
NULL, 0, NULL, 0);
|
|
|
|
|
|
|
|
setup_child_process(s, &apply_worktree,
|
|
|
|
"apply", reverse, NULL);
|
|
|
|
pipe_command(&apply_worktree, diff->buf, diff->len,
|
|
|
|
NULL, 0, NULL, 0);
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!applies_index) {
|
|
|
|
err(s, _("The selected hunks do not apply to the index!"));
|
|
|
|
if (prompt_yesno(s, _("Apply them to the worktree "
|
|
|
|
"anyway? ")) > 0) {
|
|
|
|
setup_child_process(s, &apply_worktree,
|
|
|
|
"apply", reverse, NULL);
|
|
|
|
return pipe_command(&apply_worktree, diff->buf,
|
|
|
|
diff->len, NULL, 0, NULL, 0);
|
|
|
|
}
|
|
|
|
err(s, _("Nothing was applied.\n"));
|
|
|
|
} else
|
|
|
|
/* As a last resort, show the diff to the user */
|
2024-04-30 02:37:03 +08:00
|
|
|
fwrite(diff->buf, diff->len, 1, stdout);
|
2019-12-22 05:57:14 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-12-13 16:08:02 +08:00
|
|
|
#define SUMMARY_HEADER_WIDTH 20
|
|
|
|
#define SUMMARY_LINE_WIDTH 80
|
|
|
|
static void summarize_hunk(struct add_p_state *s, struct hunk *hunk,
|
|
|
|
struct strbuf *out)
|
|
|
|
{
|
|
|
|
struct hunk_header *header = &hunk->header;
|
|
|
|
struct strbuf *plain = &s->plain;
|
|
|
|
size_t len = out->len, i;
|
|
|
|
|
|
|
|
strbuf_addf(out, " -%lu,%lu +%lu,%lu ",
|
|
|
|
header->old_offset, header->old_count,
|
|
|
|
header->new_offset, header->new_count);
|
|
|
|
if (out->len - len < SUMMARY_HEADER_WIDTH)
|
|
|
|
strbuf_addchars(out, ' ',
|
|
|
|
SUMMARY_HEADER_WIDTH + len - out->len);
|
|
|
|
for (i = hunk->start; i < hunk->end; i = find_next_line(plain, i))
|
|
|
|
if (plain->buf[i] != ' ')
|
|
|
|
break;
|
|
|
|
if (i < hunk->end)
|
|
|
|
strbuf_add(out, plain->buf + i, find_next_line(plain, i) - i);
|
|
|
|
if (out->len - len > SUMMARY_LINE_WIDTH)
|
|
|
|
strbuf_setlen(out, len + SUMMARY_LINE_WIDTH);
|
|
|
|
strbuf_complete_line(out);
|
|
|
|
}
|
|
|
|
|
|
|
|
#define DISPLAY_HUNKS_LINES 20
|
|
|
|
static size_t display_hunks(struct add_p_state *s,
|
|
|
|
struct file_diff *file_diff, size_t start_index)
|
|
|
|
{
|
|
|
|
size_t end_index = start_index + DISPLAY_HUNKS_LINES;
|
|
|
|
|
|
|
|
if (end_index > file_diff->hunk_nr)
|
|
|
|
end_index = file_diff->hunk_nr;
|
|
|
|
|
|
|
|
while (start_index < end_index) {
|
|
|
|
struct hunk *hunk = file_diff->hunk + start_index++;
|
|
|
|
|
|
|
|
strbuf_reset(&s->buf);
|
|
|
|
strbuf_addf(&s->buf, "%c%2d: ", hunk->use == USE_HUNK ? '+'
|
|
|
|
: hunk->use == SKIP_HUNK ? '-' : ' ',
|
|
|
|
(int)start_index);
|
|
|
|
summarize_hunk(s, hunk, &s->buf);
|
|
|
|
fputs(s->buf.buf, stdout);
|
|
|
|
}
|
|
|
|
|
|
|
|
return end_index;
|
|
|
|
}
|
|
|
|
|
2019-12-13 16:08:05 +08:00
|
|
|
static const char help_patch_remainder[] =
|
|
|
|
N_("j - leave this hunk undecided, see next undecided hunk\n"
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
"J - leave this hunk undecided, see next hunk\n"
|
|
|
|
"k - leave this hunk undecided, see previous undecided hunk\n"
|
|
|
|
"K - leave this hunk undecided, see previous hunk\n"
|
2019-12-13 16:08:02 +08:00
|
|
|
"g - select a hunk to go to\n"
|
2019-12-13 16:08:03 +08:00
|
|
|
"/ - search for a hunk matching the given regex\n"
|
built-in add -p: implement the hunk splitting feature
If this developer's workflow is any indication, then this is *the* most
useful feature of Git's interactive `add `command.
Note: once again, this is not a verbatim conversion from the Perl code
to C: the `hunk_splittable()` function, for example, essentially did all
the work of splitting the hunk, just to find out whether more than one
hunk would have been the result (and then tossed that result into the
trash). In C we instead count the number of resulting hunks (without
actually doing the work of splitting, but just counting the transitions
from non-context lines to context lines), and store that information
with the hunk, and we do that *while* parsing the diff in the first
place.
Another deviation: the built-in `git add -p` was designed with a single
strbuf holding the diff (and another one holding the colored diff, if
that one was asked for) in mind, and hunks essentially store just the
start and end offsets pointing into that strbuf. As a consequence, when
we split hunks, we now use a special mode where the hunk header is
generated dynamically, and only the rest of the hunk is stored using
such start/end offsets. This way, we also avoid the frequent
formatting/re-parsing of the hunk header of the Perl version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:58 +08:00
|
|
|
"s - split the current hunk into smaller hunks\n"
|
2019-12-13 16:08:01 +08:00
|
|
|
"e - manually edit the current hunk\n"
|
2024-03-29 11:58:28 +08:00
|
|
|
"p - print the current hunk\n"
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
"? - print help\n");
|
|
|
|
|
2019-12-13 16:07:54 +08:00
|
|
|
static int patch_update_file(struct add_p_state *s,
|
|
|
|
struct file_diff *file_diff)
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
{
|
|
|
|
size_t hunk_index = 0;
|
add-patch: do not print hunks repeatedly
The interactive-patch is a sequential process where, on each step, we
print one hunk from a patch and then ask the user how to proceed.
There is a possibility of repeating a step, for example if the user
enters a non-applicable option, i.e: "s"
$ git add -p
diff --git a/add-patch.c b/add-patch.c
index 52be1ddb15..8fb75e82e2 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? s
Sorry, cannot split this hunk
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
... or an invalid option, i.e: "U"
$ git add -p
diff --git a/add-patch.c b/add-patch.c
index 52be1ddb15..8fb75e82e2 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? U
y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
g - select a hunk to go to
/ - search for a hunk matching the given regex
e - manually edit the current hunk
p - print again the current hunk
? - print help
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
Printing the chunk again followed by the question can be confusing as
the user has to pay special attention to notice that the same chunk is
being reconsidered.
It can also be problematic if the chunk is longer than one screen height
because the result of the previous iteration is lost off the screen (the
help guide in the previous example).
To avoid such problems, stop printing the chunk if the iteration does
not advance to a different chunk.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-29 11:58:52 +08:00
|
|
|
ssize_t i, undecided_previous, undecided_next, rendered_hunk_index = -1;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
struct hunk *hunk;
|
|
|
|
char ch;
|
|
|
|
struct child_process cp = CHILD_PROCESS_INIT;
|
2019-12-13 16:08:04 +08:00
|
|
|
int colored = !!s->colored.len, quit = 0;
|
2019-12-13 16:07:57 +08:00
|
|
|
enum prompt_mode_type prompt_mode_type;
|
2020-08-17 21:23:08 +08:00
|
|
|
enum {
|
|
|
|
ALLOW_GOTO_PREVIOUS_HUNK = 1 << 0,
|
|
|
|
ALLOW_GOTO_PREVIOUS_UNDECIDED_HUNK = 1 << 1,
|
|
|
|
ALLOW_GOTO_NEXT_HUNK = 1 << 2,
|
|
|
|
ALLOW_GOTO_NEXT_UNDECIDED_HUNK = 1 << 3,
|
|
|
|
ALLOW_SEARCH_AND_GOTO = 1 << 4,
|
|
|
|
ALLOW_SPLIT = 1 << 5,
|
|
|
|
ALLOW_EDIT = 1 << 6
|
|
|
|
} permitted = 0;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
|
2020-09-09 21:58:52 +08:00
|
|
|
/* Empty added files have no hunks */
|
|
|
|
if (!file_diff->hunk_nr && !file_diff->added)
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
strbuf_reset(&s->buf);
|
2019-12-13 16:07:56 +08:00
|
|
|
render_diff_header(s, file_diff, colored, &s->buf);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
fputs(s->buf.buf, stdout);
|
|
|
|
for (;;) {
|
2019-12-13 16:07:54 +08:00
|
|
|
if (hunk_index >= file_diff->hunk_nr)
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
hunk_index = 0;
|
2020-09-09 21:58:52 +08:00
|
|
|
hunk = file_diff->hunk_nr
|
|
|
|
? file_diff->hunk + hunk_index
|
|
|
|
: &file_diff->head;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
undecided_previous = -1;
|
|
|
|
undecided_next = -1;
|
2020-09-09 21:58:52 +08:00
|
|
|
|
|
|
|
if (file_diff->hunk_nr) {
|
|
|
|
for (i = hunk_index - 1; i >= 0; i--)
|
|
|
|
if (file_diff->hunk[i].use == UNDECIDED_HUNK) {
|
|
|
|
undecided_previous = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = hunk_index + 1; i < file_diff->hunk_nr; i++)
|
|
|
|
if (file_diff->hunk[i].use == UNDECIDED_HUNK) {
|
|
|
|
undecided_next = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
|
|
|
|
/* Everything decided? */
|
|
|
|
if (undecided_previous < 0 && undecided_next < 0 &&
|
|
|
|
hunk->use != UNDECIDED_HUNK)
|
|
|
|
break;
|
|
|
|
|
|
|
|
strbuf_reset(&s->buf);
|
2020-09-09 21:58:52 +08:00
|
|
|
if (file_diff->hunk_nr) {
|
add-patch: do not print hunks repeatedly
The interactive-patch is a sequential process where, on each step, we
print one hunk from a patch and then ask the user how to proceed.
There is a possibility of repeating a step, for example if the user
enters a non-applicable option, i.e: "s"
$ git add -p
diff --git a/add-patch.c b/add-patch.c
index 52be1ddb15..8fb75e82e2 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? s
Sorry, cannot split this hunk
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
... or an invalid option, i.e: "U"
$ git add -p
diff --git a/add-patch.c b/add-patch.c
index 52be1ddb15..8fb75e82e2 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? U
y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
g - select a hunk to go to
/ - search for a hunk matching the given regex
e - manually edit the current hunk
p - print again the current hunk
? - print help
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
Printing the chunk again followed by the question can be confusing as
the user has to pay special attention to notice that the same chunk is
being reconsidered.
It can also be problematic if the chunk is longer than one screen height
because the result of the previous iteration is lost off the screen (the
help guide in the previous example).
To avoid such problems, stop printing the chunk if the iteration does
not advance to a different chunk.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-29 11:58:52 +08:00
|
|
|
if (rendered_hunk_index != hunk_index) {
|
|
|
|
render_hunk(s, hunk, 0, colored, &s->buf);
|
|
|
|
fputs(s->buf.buf, stdout);
|
|
|
|
rendered_hunk_index = hunk_index;
|
|
|
|
}
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
|
2020-09-09 21:58:52 +08:00
|
|
|
strbuf_reset(&s->buf);
|
|
|
|
if (undecided_previous >= 0) {
|
|
|
|
permitted |= ALLOW_GOTO_PREVIOUS_UNDECIDED_HUNK;
|
|
|
|
strbuf_addstr(&s->buf, ",k");
|
|
|
|
}
|
|
|
|
if (hunk_index) {
|
|
|
|
permitted |= ALLOW_GOTO_PREVIOUS_HUNK;
|
|
|
|
strbuf_addstr(&s->buf, ",K");
|
|
|
|
}
|
|
|
|
if (undecided_next >= 0) {
|
|
|
|
permitted |= ALLOW_GOTO_NEXT_UNDECIDED_HUNK;
|
|
|
|
strbuf_addstr(&s->buf, ",j");
|
|
|
|
}
|
|
|
|
if (hunk_index + 1 < file_diff->hunk_nr) {
|
|
|
|
permitted |= ALLOW_GOTO_NEXT_HUNK;
|
|
|
|
strbuf_addstr(&s->buf, ",J");
|
|
|
|
}
|
|
|
|
if (file_diff->hunk_nr > 1) {
|
|
|
|
permitted |= ALLOW_SEARCH_AND_GOTO;
|
|
|
|
strbuf_addstr(&s->buf, ",g,/");
|
|
|
|
}
|
|
|
|
if (hunk->splittable_into > 1) {
|
|
|
|
permitted |= ALLOW_SPLIT;
|
|
|
|
strbuf_addstr(&s->buf, ",s");
|
|
|
|
}
|
|
|
|
if (hunk_index + 1 > file_diff->mode_change &&
|
|
|
|
!file_diff->deleted) {
|
|
|
|
permitted |= ALLOW_EDIT;
|
|
|
|
strbuf_addstr(&s->buf, ",e");
|
|
|
|
}
|
2024-03-29 11:58:28 +08:00
|
|
|
strbuf_addstr(&s->buf, ",p");
|
2020-08-17 21:23:08 +08:00
|
|
|
}
|
2019-12-13 16:07:57 +08:00
|
|
|
if (file_diff->deleted)
|
|
|
|
prompt_mode_type = PROMPT_DELETION;
|
2020-05-28 05:09:06 +08:00
|
|
|
else if (file_diff->added)
|
|
|
|
prompt_mode_type = PROMPT_ADDITION;
|
2019-12-13 16:07:57 +08:00
|
|
|
else if (file_diff->mode_change && !hunk_index)
|
|
|
|
prompt_mode_type = PROMPT_MODE_CHANGE;
|
|
|
|
else
|
|
|
|
prompt_mode_type = PROMPT_HUNK;
|
|
|
|
|
2020-11-17 00:08:28 +08:00
|
|
|
printf("%s(%"PRIuMAX"/%"PRIuMAX") ", s->s.prompt_color,
|
2019-12-13 16:07:54 +08:00
|
|
|
(uintmax_t)hunk_index + 1,
|
2020-09-09 21:58:52 +08:00
|
|
|
(uintmax_t)(file_diff->hunk_nr
|
|
|
|
? file_diff->hunk_nr
|
|
|
|
: 1));
|
2020-11-17 00:08:28 +08:00
|
|
|
printf(_(s->mode->prompt_mode[prompt_mode_type]),
|
|
|
|
s->buf.buf);
|
|
|
|
if (*s->s.reset_color)
|
|
|
|
fputs(s->s.reset_color, stdout);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
fflush(stdout);
|
2020-01-15 02:43:50 +08:00
|
|
|
if (read_single_character(s) == EOF)
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
if (!s->answer.len)
|
|
|
|
continue;
|
|
|
|
ch = tolower(s->answer.buf[0]);
|
add-patch: enforce only one-letter response to prompts
In a "git add -p" session, especially when we are not using the
single-key mode, we may see 'qa' as a response to a prompt
(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
and then just do the 'q' thing (i.e. quit the session), ignoring
everything other than the first byte.
If 'q' and 'a' are next to each other on the user's keyboard, there
is a plausible chance that we see 'qa' when the user who wanted to
say 'a' fat-fingered and we ended up doing the 'q' thing instead.
As we didn't think of a good reason during the review discussion why
we want to accept excess letters only to ignore them, it appears to
be a safe change to simply reject input that is longer than just one
byte.
The two exceptions are the 'g' command that takes a hunk number, and
the '/' command that takes a regular expression. They have to be
accompanied by their operands (this makes me wonder how users who
set the interactive.singlekey configuration feed these operands---it
turns out that we notice there is no operand and give them another
chance to type the operand separately, without using single key
input this time), so we accept a string that is more than one byte
long.
Keep the "use only the first byte, downcased" behaviour when we ask
yes/no question, though. Neither on Qwerty or on Dvorak, 'y' and
'n' are not close to each other.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-05-23 05:45:48 +08:00
|
|
|
|
|
|
|
/* 'g' takes a hunk number and '/' takes a regexp */
|
|
|
|
if (s->answer.len != 1 && (ch != 'g' && ch != '/')) {
|
|
|
|
err(s, _("Only one letter is expected, got '%s'"), s->answer.buf);
|
|
|
|
continue;
|
|
|
|
}
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
if (ch == 'y') {
|
|
|
|
hunk->use = USE_HUNK;
|
|
|
|
soft_increment:
|
|
|
|
hunk_index = undecided_next < 0 ?
|
2019-12-13 16:07:54 +08:00
|
|
|
file_diff->hunk_nr : undecided_next;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
} else if (ch == 'n') {
|
|
|
|
hunk->use = SKIP_HUNK;
|
|
|
|
goto soft_increment;
|
|
|
|
} else if (ch == 'a') {
|
2020-09-09 21:58:52 +08:00
|
|
|
if (file_diff->hunk_nr) {
|
|
|
|
for (; hunk_index < file_diff->hunk_nr; hunk_index++) {
|
|
|
|
hunk = file_diff->hunk + hunk_index;
|
|
|
|
if (hunk->use == UNDECIDED_HUNK)
|
|
|
|
hunk->use = USE_HUNK;
|
|
|
|
}
|
|
|
|
} else if (hunk->use == UNDECIDED_HUNK) {
|
|
|
|
hunk->use = USE_HUNK;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
}
|
2019-12-13 16:08:04 +08:00
|
|
|
} else if (ch == 'd' || ch == 'q') {
|
2020-09-09 21:58:52 +08:00
|
|
|
if (file_diff->hunk_nr) {
|
|
|
|
for (; hunk_index < file_diff->hunk_nr; hunk_index++) {
|
|
|
|
hunk = file_diff->hunk + hunk_index;
|
|
|
|
if (hunk->use == UNDECIDED_HUNK)
|
|
|
|
hunk->use = SKIP_HUNK;
|
|
|
|
}
|
|
|
|
} else if (hunk->use == UNDECIDED_HUNK) {
|
|
|
|
hunk->use = SKIP_HUNK;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
}
|
2019-12-13 16:08:04 +08:00
|
|
|
if (ch == 'q') {
|
|
|
|
quit = 1;
|
|
|
|
break;
|
|
|
|
}
|
2019-12-13 16:07:53 +08:00
|
|
|
} else if (s->answer.buf[0] == 'K') {
|
2020-08-17 21:23:08 +08:00
|
|
|
if (permitted & ALLOW_GOTO_PREVIOUS_HUNK)
|
2019-12-13 16:07:53 +08:00
|
|
|
hunk_index--;
|
|
|
|
else
|
|
|
|
err(s, _("No previous hunk"));
|
|
|
|
} else if (s->answer.buf[0] == 'J') {
|
2020-08-17 21:23:08 +08:00
|
|
|
if (permitted & ALLOW_GOTO_NEXT_HUNK)
|
2019-12-13 16:07:53 +08:00
|
|
|
hunk_index++;
|
|
|
|
else
|
|
|
|
err(s, _("No next hunk"));
|
|
|
|
} else if (s->answer.buf[0] == 'k') {
|
2020-08-17 21:23:08 +08:00
|
|
|
if (permitted & ALLOW_GOTO_PREVIOUS_UNDECIDED_HUNK)
|
2019-12-13 16:07:53 +08:00
|
|
|
hunk_index = undecided_previous;
|
|
|
|
else
|
|
|
|
err(s, _("No previous hunk"));
|
|
|
|
} else if (s->answer.buf[0] == 'j') {
|
2020-08-17 21:23:08 +08:00
|
|
|
if (permitted & ALLOW_GOTO_NEXT_UNDECIDED_HUNK)
|
2019-12-13 16:07:53 +08:00
|
|
|
hunk_index = undecided_next;
|
|
|
|
else
|
|
|
|
err(s, _("No next hunk"));
|
2019-12-13 16:08:02 +08:00
|
|
|
} else if (s->answer.buf[0] == 'g') {
|
|
|
|
char *pend;
|
|
|
|
unsigned long response;
|
|
|
|
|
2020-08-17 21:23:08 +08:00
|
|
|
if (!(permitted & ALLOW_SEARCH_AND_GOTO)) {
|
2019-12-13 16:08:02 +08:00
|
|
|
err(s, _("No other hunks to goto"));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
strbuf_remove(&s->answer, 0, 1);
|
|
|
|
strbuf_trim(&s->answer);
|
|
|
|
i = hunk_index - DISPLAY_HUNKS_LINES / 2;
|
add -p: avoid ambiguous signed/unsigned comparison
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>
2022-08-30 21:54:22 +08:00
|
|
|
if (i < (int)file_diff->mode_change)
|
2019-12-13 16:08:02 +08:00
|
|
|
i = file_diff->mode_change;
|
|
|
|
while (s->answer.len == 0) {
|
|
|
|
i = display_hunks(s, file_diff, i);
|
|
|
|
printf("%s", i < file_diff->hunk_nr ?
|
|
|
|
_("go to which hunk (<ret> to see "
|
|
|
|
"more)? ") : _("go to which hunk? "));
|
|
|
|
fflush(stdout);
|
|
|
|
if (strbuf_getline(&s->answer,
|
|
|
|
stdin) == EOF)
|
|
|
|
break;
|
|
|
|
strbuf_trim_trailing_newline(&s->answer);
|
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_trim(&s->answer);
|
|
|
|
response = strtoul(s->answer.buf, &pend, 10);
|
|
|
|
if (*pend || pend == s->answer.buf)
|
|
|
|
err(s, _("Invalid number: '%s'"),
|
|
|
|
s->answer.buf);
|
|
|
|
else if (0 < response && response <= file_diff->hunk_nr)
|
|
|
|
hunk_index = response - 1;
|
|
|
|
else
|
|
|
|
err(s, Q_("Sorry, only %d hunk available.",
|
|
|
|
"Sorry, only %d hunks available.",
|
|
|
|
file_diff->hunk_nr),
|
|
|
|
(int)file_diff->hunk_nr);
|
2019-12-13 16:08:03 +08:00
|
|
|
} else if (s->answer.buf[0] == '/') {
|
|
|
|
regex_t regex;
|
|
|
|
int ret;
|
|
|
|
|
2020-08-17 21:23:08 +08:00
|
|
|
if (!(permitted & ALLOW_SEARCH_AND_GOTO)) {
|
2019-12-13 16:08:03 +08:00
|
|
|
err(s, _("No other hunks to search"));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
strbuf_remove(&s->answer, 0, 1);
|
|
|
|
strbuf_trim_trailing_newline(&s->answer);
|
|
|
|
if (s->answer.len == 0) {
|
|
|
|
printf("%s", _("search for regex? "));
|
|
|
|
fflush(stdout);
|
|
|
|
if (strbuf_getline(&s->answer,
|
|
|
|
stdin) == EOF)
|
|
|
|
break;
|
|
|
|
strbuf_trim_trailing_newline(&s->answer);
|
|
|
|
if (s->answer.len == 0)
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
ret = regcomp(®ex, s->answer.buf,
|
|
|
|
REG_EXTENDED | REG_NOSUB | REG_NEWLINE);
|
|
|
|
if (ret) {
|
|
|
|
char errbuf[1024];
|
|
|
|
|
|
|
|
regerror(ret, ®ex, errbuf, sizeof(errbuf));
|
|
|
|
err(s, _("Malformed search regexp %s: %s"),
|
|
|
|
s->answer.buf, errbuf);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
i = hunk_index;
|
|
|
|
for (;;) {
|
|
|
|
/* render the hunk into a scratch buffer */
|
|
|
|
render_hunk(s, file_diff->hunk + i, 0, 0,
|
|
|
|
&s->buf);
|
|
|
|
if (regexec(®ex, s->buf.buf, 0, NULL, 0)
|
|
|
|
!= REG_NOMATCH)
|
|
|
|
break;
|
|
|
|
i++;
|
|
|
|
if (i == file_diff->hunk_nr)
|
|
|
|
i = 0;
|
|
|
|
if (i != hunk_index)
|
|
|
|
continue;
|
|
|
|
err(s, _("No hunk matches the given pattern"));
|
|
|
|
break;
|
|
|
|
}
|
2024-04-23 06:54:14 +08:00
|
|
|
regfree(®ex);
|
2019-12-13 16:08:03 +08:00
|
|
|
hunk_index = i;
|
built-in add -p: implement the hunk splitting feature
If this developer's workflow is any indication, then this is *the* most
useful feature of Git's interactive `add `command.
Note: once again, this is not a verbatim conversion from the Perl code
to C: the `hunk_splittable()` function, for example, essentially did all
the work of splitting the hunk, just to find out whether more than one
hunk would have been the result (and then tossed that result into the
trash). In C we instead count the number of resulting hunks (without
actually doing the work of splitting, but just counting the transitions
from non-context lines to context lines), and store that information
with the hunk, and we do that *while* parsing the diff in the first
place.
Another deviation: the built-in `git add -p` was designed with a single
strbuf holding the diff (and another one holding the colored diff, if
that one was asked for) in mind, and hunks essentially store just the
start and end offsets pointing into that strbuf. As a consequence, when
we split hunks, we now use a special mode where the hunk header is
generated dynamically, and only the rest of the hunk is stored using
such start/end offsets. This way, we also avoid the frequent
formatting/re-parsing of the hunk header of the Perl version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:58 +08:00
|
|
|
} else if (s->answer.buf[0] == 's') {
|
|
|
|
size_t splittable_into = hunk->splittable_into;
|
add-patch: do not print hunks repeatedly
The interactive-patch is a sequential process where, on each step, we
print one hunk from a patch and then ask the user how to proceed.
There is a possibility of repeating a step, for example if the user
enters a non-applicable option, i.e: "s"
$ git add -p
diff --git a/add-patch.c b/add-patch.c
index 52be1ddb15..8fb75e82e2 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? s
Sorry, cannot split this hunk
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
... or an invalid option, i.e: "U"
$ git add -p
diff --git a/add-patch.c b/add-patch.c
index 52be1ddb15..8fb75e82e2 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? U
y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
g - select a hunk to go to
/ - search for a hunk matching the given regex
e - manually edit the current hunk
p - print again the current hunk
? - print help
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
Printing the chunk again followed by the question can be confusing as
the user has to pay special attention to notice that the same chunk is
being reconsidered.
It can also be problematic if the chunk is longer than one screen height
because the result of the previous iteration is lost off the screen (the
help guide in the previous example).
To avoid such problems, stop printing the chunk if the iteration does
not advance to a different chunk.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-29 11:58:52 +08:00
|
|
|
if (!(permitted & ALLOW_SPLIT)) {
|
built-in add -p: implement the hunk splitting feature
If this developer's workflow is any indication, then this is *the* most
useful feature of Git's interactive `add `command.
Note: once again, this is not a verbatim conversion from the Perl code
to C: the `hunk_splittable()` function, for example, essentially did all
the work of splitting the hunk, just to find out whether more than one
hunk would have been the result (and then tossed that result into the
trash). In C we instead count the number of resulting hunks (without
actually doing the work of splitting, but just counting the transitions
from non-context lines to context lines), and store that information
with the hunk, and we do that *while* parsing the diff in the first
place.
Another deviation: the built-in `git add -p` was designed with a single
strbuf holding the diff (and another one holding the colored diff, if
that one was asked for) in mind, and hunks essentially store just the
start and end offsets pointing into that strbuf. As a consequence, when
we split hunks, we now use a special mode where the hunk header is
generated dynamically, and only the rest of the hunk is stored using
such start/end offsets. This way, we also avoid the frequent
formatting/re-parsing of the hunk header of the Perl version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:58 +08:00
|
|
|
err(s, _("Sorry, cannot split this hunk"));
|
add-patch: do not print hunks repeatedly
The interactive-patch is a sequential process where, on each step, we
print one hunk from a patch and then ask the user how to proceed.
There is a possibility of repeating a step, for example if the user
enters a non-applicable option, i.e: "s"
$ git add -p
diff --git a/add-patch.c b/add-patch.c
index 52be1ddb15..8fb75e82e2 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? s
Sorry, cannot split this hunk
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
... or an invalid option, i.e: "U"
$ git add -p
diff --git a/add-patch.c b/add-patch.c
index 52be1ddb15..8fb75e82e2 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? U
y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
g - select a hunk to go to
/ - search for a hunk matching the given regex
e - manually edit the current hunk
p - print again the current hunk
? - print help
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
Printing the chunk again followed by the question can be confusing as
the user has to pay special attention to notice that the same chunk is
being reconsidered.
It can also be problematic if the chunk is longer than one screen height
because the result of the previous iteration is lost off the screen (the
help guide in the previous example).
To avoid such problems, stop printing the chunk if the iteration does
not advance to a different chunk.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-29 11:58:52 +08:00
|
|
|
} else if (!split_hunk(s, file_diff,
|
|
|
|
hunk - file_diff->hunk)) {
|
built-in add -p: implement the hunk splitting feature
If this developer's workflow is any indication, then this is *the* most
useful feature of Git's interactive `add `command.
Note: once again, this is not a verbatim conversion from the Perl code
to C: the `hunk_splittable()` function, for example, essentially did all
the work of splitting the hunk, just to find out whether more than one
hunk would have been the result (and then tossed that result into the
trash). In C we instead count the number of resulting hunks (without
actually doing the work of splitting, but just counting the transitions
from non-context lines to context lines), and store that information
with the hunk, and we do that *while* parsing the diff in the first
place.
Another deviation: the built-in `git add -p` was designed with a single
strbuf holding the diff (and another one holding the colored diff, if
that one was asked for) in mind, and hunks essentially store just the
start and end offsets pointing into that strbuf. As a consequence, when
we split hunks, we now use a special mode where the hunk header is
generated dynamically, and only the rest of the hunk is stored using
such start/end offsets. This way, we also avoid the frequent
formatting/re-parsing of the hunk header of the Perl version.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:58 +08:00
|
|
|
color_fprintf_ln(stdout, s->s.header_color,
|
|
|
|
_("Split into %d hunks."),
|
|
|
|
(int)splittable_into);
|
add-patch: do not print hunks repeatedly
The interactive-patch is a sequential process where, on each step, we
print one hunk from a patch and then ask the user how to proceed.
There is a possibility of repeating a step, for example if the user
enters a non-applicable option, i.e: "s"
$ git add -p
diff --git a/add-patch.c b/add-patch.c
index 52be1ddb15..8fb75e82e2 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? s
Sorry, cannot split this hunk
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
... or an invalid option, i.e: "U"
$ git add -p
diff --git a/add-patch.c b/add-patch.c
index 52be1ddb15..8fb75e82e2 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? U
y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
g - select a hunk to go to
/ - search for a hunk matching the given regex
e - manually edit the current hunk
p - print again the current hunk
? - print help
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
Printing the chunk again followed by the question can be confusing as
the user has to pay special attention to notice that the same chunk is
being reconsidered.
It can also be problematic if the chunk is longer than one screen height
because the result of the previous iteration is lost off the screen (the
help guide in the previous example).
To avoid such problems, stop printing the chunk if the iteration does
not advance to a different chunk.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-29 11:58:52 +08:00
|
|
|
rendered_hunk_index = -1;
|
|
|
|
}
|
2019-12-13 16:08:01 +08:00
|
|
|
} else if (s->answer.buf[0] == 'e') {
|
2020-08-17 21:23:08 +08:00
|
|
|
if (!(permitted & ALLOW_EDIT))
|
2019-12-13 16:08:01 +08:00
|
|
|
err(s, _("Sorry, cannot edit this hunk"));
|
|
|
|
else if (edit_hunk_loop(s, file_diff, hunk) >= 0) {
|
|
|
|
hunk->use = USE_HUNK;
|
|
|
|
goto soft_increment;
|
|
|
|
}
|
2024-03-29 11:58:28 +08:00
|
|
|
} else if (s->answer.buf[0] == 'p') {
|
add-patch: do not print hunks repeatedly
The interactive-patch is a sequential process where, on each step, we
print one hunk from a patch and then ask the user how to proceed.
There is a possibility of repeating a step, for example if the user
enters a non-applicable option, i.e: "s"
$ git add -p
diff --git a/add-patch.c b/add-patch.c
index 52be1ddb15..8fb75e82e2 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? s
Sorry, cannot split this hunk
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
... or an invalid option, i.e: "U"
$ git add -p
diff --git a/add-patch.c b/add-patch.c
index 52be1ddb15..8fb75e82e2 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? U
y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
g - select a hunk to go to
/ - search for a hunk matching the given regex
e - manually edit the current hunk
p - print again the current hunk
? - print help
@@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n"
static int patch_update_file(struct add_p_state *s,
struct file_diff *file_diff)
{
- size_t hunk_index = 0;
+ size_t hunk_index = 0, prev_hunk_index = -1;
ssize_t i, undecided_previous, undecided_next;
struct hunk *hunk;
char ch;
(1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
Printing the chunk again followed by the question can be confusing as
the user has to pay special attention to notice that the same chunk is
being reconsidered.
It can also be problematic if the chunk is longer than one screen height
because the result of the previous iteration is lost off the screen (the
help guide in the previous example).
To avoid such problems, stop printing the chunk if the iteration does
not advance to a different chunk.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-29 11:58:52 +08:00
|
|
|
rendered_hunk_index = -1;
|
2024-04-30 02:37:12 +08:00
|
|
|
} else if (s->answer.buf[0] == '?') {
|
2019-12-13 16:08:05 +08:00
|
|
|
const char *p = _(help_patch_remainder), *eol = p;
|
|
|
|
|
|
|
|
color_fprintf(stdout, s->s.help_color, "%s",
|
2019-12-22 05:57:10 +08:00
|
|
|
_(s->mode->help_patch_text));
|
2019-12-13 16:08:05 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Show only those lines of the remainder that are
|
|
|
|
* actually applicable with the current hunk.
|
|
|
|
*/
|
|
|
|
for (; *p; p = eol + (*eol == '\n')) {
|
|
|
|
eol = strchrnul(p, '\n');
|
|
|
|
|
|
|
|
/*
|
|
|
|
* `s->buf` still contains the part of the
|
|
|
|
* commands shown in the prompt that are not
|
|
|
|
* always available.
|
|
|
|
*/
|
|
|
|
if (*p != '?' && !strchr(s->buf.buf, *p))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
color_fprintf_ln(stdout, s->s.help_color,
|
|
|
|
"%.*s", (int)(eol - p), p);
|
|
|
|
}
|
2024-04-30 02:37:12 +08:00
|
|
|
} else {
|
|
|
|
err(s, _("Unknown command '%s' (use '?' for help)"),
|
|
|
|
s->answer.buf);
|
2019-12-13 16:08:05 +08:00
|
|
|
}
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Any hunk to be used? */
|
2019-12-13 16:07:54 +08:00
|
|
|
for (i = 0; i < file_diff->hunk_nr; i++)
|
|
|
|
if (file_diff->hunk[i].use == USE_HUNK)
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
break;
|
|
|
|
|
2020-09-09 21:58:52 +08:00
|
|
|
if (i < file_diff->hunk_nr ||
|
|
|
|
(!file_diff->hunk_nr && file_diff->head.use == USE_HUNK)) {
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
/* At least one hunk selected: apply */
|
|
|
|
strbuf_reset(&s->buf);
|
2019-12-13 16:08:01 +08:00
|
|
|
reassemble_patch(s, file_diff, 0, &s->buf);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
discard_index(s->s.r->index);
|
2019-12-22 05:57:14 +08:00
|
|
|
if (s->mode->apply_for_checkout)
|
|
|
|
apply_for_checkout(s, &s->buf,
|
|
|
|
s->mode->is_reverse);
|
|
|
|
else {
|
|
|
|
setup_child_process(s, &cp, "apply", NULL);
|
2020-07-29 04:24:53 +08:00
|
|
|
strvec_pushv(&cp.args, s->mode->apply_args);
|
2019-12-22 05:57:14 +08:00
|
|
|
if (pipe_command(&cp, s->buf.buf, s->buf.len,
|
|
|
|
NULL, 0, NULL, 0))
|
|
|
|
error(_("'git apply' failed"));
|
|
|
|
}
|
2020-09-07 16:08:53 +08:00
|
|
|
if (repo_read_index(s->s.r) >= 0)
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
repo_refresh_and_write_index(s->s.r, REFRESH_QUIET, 0,
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
1, NULL, NULL, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
putchar('\n');
|
2019-12-13 16:08:04 +08:00
|
|
|
return quit;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
}
|
|
|
|
|
2019-12-22 05:57:10 +08:00
|
|
|
int run_add_p(struct repository *r, enum add_p_mode mode,
|
|
|
|
const char *revision, const struct pathspec *ps)
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
{
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
struct add_p_state s = {
|
|
|
|
{ r }, STRBUF_INIT, STRBUF_INIT, STRBUF_INIT, STRBUF_INIT
|
|
|
|
};
|
2019-12-13 16:08:06 +08:00
|
|
|
size_t i, binary_count = 0;
|
built-in add -p: adjust hunk headers as needed
When skipping a hunk that adds a different number of lines than it
removes, we need to adjust the subsequent hunk headers of non-skipped
hunks: in pathological cases, the context is not enough to determine
precisely where the patch should be applied.
This problem was identified in 23fea4c240 (t3701: add failing test for
pathological context lines, 2018-03-01) and fixed in the Perl version in
fecc6f3a68 (add -p: adjust offsets of subsequent hunks when one is
skipped, 2018-03-01).
And this patch fixes it in the C version of `git add -p`.
In contrast to the Perl version, we try to keep the extra text on the
hunk header (which typically contains the signature of the function
whose code is changed in the hunk) intact.
Note: while the C version does not support staging mode changes at this
stage, we already prepare for this by simply skipping the hunk header if
both old and new offset is 0 (this cannot happen for regular hunks, and
we will use this as an indicator that we are looking at a special hunk).
Likewise, we already prepare for hunk splitting by handling the absence
of extra text in the hunk header gracefully: only the first split hunk
will have that text, the others will not (indicated by an empty extra
text start/end range). Preparing for hunk splitting already at this
stage avoids an indentation change of the entire hunk header-printing
block later, and is almost as easy to review as without that handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:51 +08:00
|
|
|
|
|
|
|
init_add_i_state(&s.s, r);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
|
2019-12-22 05:57:11 +08:00
|
|
|
if (mode == ADD_P_STASH)
|
|
|
|
s.mode = &patch_mode_stash;
|
|
|
|
else if (mode == ADD_P_RESET) {
|
|
|
|
if (!revision || !strcmp(revision, "HEAD"))
|
|
|
|
s.mode = &patch_mode_reset_head;
|
|
|
|
else
|
|
|
|
s.mode = &patch_mode_reset_nothead;
|
2019-12-22 05:57:14 +08:00
|
|
|
} else if (mode == ADD_P_CHECKOUT) {
|
|
|
|
if (!revision)
|
|
|
|
s.mode = &patch_mode_checkout_index;
|
|
|
|
else if (!strcmp(revision, "HEAD"))
|
|
|
|
s.mode = &patch_mode_checkout_head;
|
|
|
|
else
|
|
|
|
s.mode = &patch_mode_checkout_nothead;
|
2019-12-22 05:57:15 +08:00
|
|
|
} else if (mode == ADD_P_WORKTREE) {
|
|
|
|
if (!revision)
|
|
|
|
s.mode = &patch_mode_checkout_index;
|
|
|
|
else if (!strcmp(revision, "HEAD"))
|
|
|
|
s.mode = &patch_mode_worktree_head;
|
|
|
|
else
|
|
|
|
s.mode = &patch_mode_worktree_nothead;
|
2019-12-22 05:57:11 +08:00
|
|
|
} else
|
|
|
|
s.mode = &patch_mode_add;
|
2019-12-22 05:57:10 +08:00
|
|
|
s.revision = revision;
|
|
|
|
|
2022-11-19 21:07:31 +08:00
|
|
|
discard_index(r->index);
|
|
|
|
if (repo_read_index(r) < 0 ||
|
2019-12-22 05:57:11 +08:00
|
|
|
(!s.mode->index_only &&
|
|
|
|
repo_refresh_and_write_index(r, REFRESH_QUIET, 0, 1,
|
|
|
|
NULL, NULL, NULL) < 0) ||
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
parse_diff(&s, ps) < 0) {
|
2020-09-07 23:04:00 +08:00
|
|
|
add_p_state_clear(&s);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2019-12-13 16:07:54 +08:00
|
|
|
for (i = 0; i < s.file_diff_nr; i++)
|
2019-12-13 16:08:06 +08:00
|
|
|
if (s.file_diff[i].binary && !s.file_diff[i].hunk_nr)
|
|
|
|
binary_count++;
|
|
|
|
else if (patch_update_file(&s, s.file_diff + i))
|
2019-12-13 16:07:54 +08:00
|
|
|
break;
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
|
2019-12-13 16:08:06 +08:00
|
|
|
if (s.file_diff_nr == 0)
|
2024-04-30 02:37:03 +08:00
|
|
|
err(&s, _("No changes."));
|
2019-12-13 16:08:06 +08:00
|
|
|
else if (binary_count == s.file_diff_nr)
|
2024-04-30 02:37:03 +08:00
|
|
|
err(&s, _("Only binary files changed."));
|
2019-12-13 16:08:06 +08:00
|
|
|
|
2020-09-07 23:04:00 +08:00
|
|
|
add_p_state_clear(&s);
|
built-in add -i: start implementing the `patch` functionality in C
In the previous steps, we re-implemented the main loop of `git add -i`
in C, and most of the commands.
Notably, we left out the actual functionality of `patch`, as the
relevant code makes up more than half of `git-add--interactive.perl`,
and is actually pretty independent of the rest of the commands.
With this commit, we start to tackle that `patch` part. For better
separation of concerns, we keep the code in a separate file,
`add-patch.c`. The new code is still guarded behind the
`add.interactive.useBuiltin` config setting, and for the moment,
it can only be called via `git add -p`.
The actual functionality follows the original implementation of
5cde71d64aff (git-add --interactive, 2006-12-10), but not too closely
(for example, we use string offsets rather than copying strings around,
and after seeing whether the `k` and `j` commands are applicable, in the
C version we remember which previous/next hunk was undecided, and use it
rather than looking again when the user asked to jump).
As a further deviation from that commit, We also use a comma instead of
a slash to separate the available commands in the prompt, as the current
version of the Perl script does this, and we also add a line about the
question mark ("print help") to the help text.
While it is tempting to use this conversion of `git add -p` as an excuse
to work on `apply_all_patches()` so that it does _not_ want to read a
file from `stdin` or from a file, but accepts, say, an `strbuf` instead,
we will refrain from this particular rabbit hole at this stage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-13 16:07:48 +08:00
|
|
|
return 0;
|
|
|
|
}
|