"Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx>
writes:
> +static int run_help(struct add_i_state *s, const struct pathspec *ps,
> + struct file_list *files, struct list_options *opts)
> +{
> + const char *help_color = s->help_color;
> +
> + color_fprintf_ln(stdout, help_color, "status - %s",
> + _("show paths with changes"));
> + color_fprintf_ln(stdout, help_color, "update - %s",
> + _("add working tree state to the staged set of changes"));
> + color_fprintf_ln(stdout, help_color, "revert - %s",
> + _("revert staged set of changes back to the HEAD version"));
> + color_fprintf_ln(stdout, help_color, "patch - %s",
> + _("pick hunks and update selectively"));
> + color_fprintf_ln(stdout, help_color, "diff - %s",
> + _("view diff between HEAD and index"));
> + color_fprintf_ln(stdout, help_color, "add untracked - %s",
> + _("add contents of untracked files to the staged set of changes"));
As we do not allow the command names to get translated, this makes
sense.
Have we adopted the convention to name callback parameters that have
to stay unused (because the callback function must have a function
signature that accepts the union of what everybody needs to take)
differently from the parameters that actually get used? It may make
sense to use it in a function like this, to prevent readers from
wasting time by wondering how pathspec is used in this function, for
example.
> diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
> index 69991a3168..cf67756b85 100755
> --- a/t/t3701-add-interactive.sh
> +++ b/t/t3701-add-interactive.sh
> @@ -647,4 +647,29 @@ test_expect_success 'checkout -p works with pathological context lines' '
> test_write_lines a b a b a a b a b a >expect &&
> test_cmp expect a
> '
> +
> +test_expect_success 'show help from add--helper' '
> + git reset --hard &&
> + cat >expect <<-EOF &&
> +
> + <BOLD>*** Commands ***<RESET>
> + 1: <BOLD;BLUE>s<RESET>tatus 2: <BOLD;BLUE>u<RESET>pdate 3: <BOLD;BLUE>r<RESET>evert 4: <BOLD;BLUE>a<RESET>dd untracked
> + 5: <BOLD;BLUE>p<RESET>atch 6: <BOLD;BLUE>d<RESET>iff 7: <BOLD;BLUE>q<RESET>uit 8: <BOLD;BLUE>h<RESET>elp
> + <BOLD;BLUE>What now<RESET>> <BOLD;RED>status - show paths with changes<RESET>
> + <BOLD;RED>update - add working tree state to the staged set of changes<RESET>
> + <BOLD;RED>revert - revert staged set of changes back to the HEAD version<RESET>
> + <BOLD;RED>patch - pick hunks and update selectively<RESET>
> + <BOLD;RED>diff - view diff between HEAD and index<RESET>
> + <BOLD;RED>add untracked - add contents of untracked files to the staged set of changes<RESET>
> + <BOLD>*** Commands ***<RESET>
> + 1: <BOLD;BLUE>s<RESET>tatus 2: <BOLD;BLUE>u<RESET>pdate 3: <BOLD;BLUE>r<RESET>evert 4: <BOLD;BLUE>a<RESET>dd untracked
> + 5: <BOLD;BLUE>p<RESET>atch 6: <BOLD;BLUE>d<RESET>iff 7: <BOLD;BLUE>q<RESET>uit 8: <BOLD;BLUE>h<RESET>elp
> + <BOLD;BLUE>What now<RESET>>$SP
> + Bye.
> + EOF
> + test_write_lines h | GIT_PAGER_IN_USE=true TERM=vt100 git add -i >actual.colored &&
> + test_decode_color <actual.colored >actual &&
> + test_i18ncmp expect actual
> +'
Nicely done.
