|
|
|
|
#ifndef ADD_INTERACTIVE_H
|
|
|
|
|
#define ADD_INTERACTIVE_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>
5 years ago
|
|
|
#include "color.h"
|
|
|
|
|
|
|
|
|
|
struct add_i_state {
|
|
|
|
|
struct repository *r;
|
|
|
|
|
int use_color;
|
|
|
|
|
char header_color[COLOR_MAXLEN];
|
|
|
|
|
char help_color[COLOR_MAXLEN];
|
|
|
|
|
char prompt_color[COLOR_MAXLEN];
|
|
|
|
|
char error_color[COLOR_MAXLEN];
|
|
|
|
|
char reset_color[COLOR_MAXLEN];
|
|
|
|
|
char fraginfo_color[COLOR_MAXLEN];
|
|
|
|
|
char context_color[COLOR_MAXLEN];
|
|
|
|
|
char file_old_color[COLOR_MAXLEN];
|
|
|
|
|
char file_new_color[COLOR_MAXLEN];
|
|
|
|
|
|
|
|
|
|
int use_single_key;
|
|
|
|
|
char *interactive_diff_filter, *interactive_diff_algorithm;
|
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>
5 years ago
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void init_add_i_state(struct add_i_state *s, struct repository *r);
|
|
|
|
|
void clear_add_i_state(struct add_i_state *s);
|
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>
5 years ago
|
|
|
|
|
|
|
|
struct repository;
|
|
|
|
|
struct pathspec;
|
|
|
|
|
int run_add_i(struct repository *r, const struct pathspec *ps);
|
|
|
|
|
|
|
|
|
|
enum add_p_mode {
|
|
|
|
|
ADD_P_ADD,
|
|
|
|
|
ADD_P_STASH,
|
|
|
|
|
ADD_P_RESET,
|
|
|
|
|
ADD_P_CHECKOUT,
|
|
|
|
|
ADD_P_WORKTREE,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int run_add_p(struct repository *r, enum add_p_mode mode,
|
|
|
|
|
const char *revision, const struct pathspec *ps);
|
|
|
|
|
|
|
|
|
|
#endif
|
