Re: Discussion for interactive --patch commands to get --unified support

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 29, 2025, 16:48 UTC
Message-ID: <xmqq34dq7w3h.fsf@gitster.g>
In-Reply-To: <CAP9jKjGb-Rcr=RLJEzeFdtrekYM+qmHy+1T1fykU3n9cV4GhGw@mail.gmail.com>

Leon Michalak <leonmichalak6@gmail.com> writes:

Show 7 quoted lines

> As I've grown to use and appreciate these features even more, I have
> noticed and been bothered that `git add --patch` doesn't have a (easy)
> way of configuring how many context lines you see. There is a
> stackoverflow post
> (https://stackoverflow.com/questions/6711670/git-show-more-context-when-using-git-add-i-or-git-add-e)
> which mentions you can do `GIT_DIFF_OPTS=-u<number> git add -p` which
> does work however isn't very user friendly or convenient.

If it is only to specify how many context lines to ask for the diff machinery when preparing the initial patch that is presented in the "add -p" UI, it should be fairly easy.

I would expect that development of such a feature would progress roughly in the following order.

 - Define "struct add_p_opt {}" that has one "unsigned int" member,
   which is the unified context length, probably in add-interactive.h;

 - Teach add-interactive.c:run_add_p() to take an extra parameter of
   type "struct add_p_opt *opt";

 - Teach builtin/add.c to take -U<n> argument, make sure to make it
   an error when '-p' or '-i' is not given and -U<n> is.  Pass it in
   that new parameter when calling run_add_p() you modified above.

 - Do the same for builtin/{checkout,reset,stash}.c where they also
   call run_add_p().

 - Add a new command (sits next to "add untracked", "patch", "diff",
   etc.) to set -U<n> in add-interactive.c:run_add_i(), so that the
   default context length of 3 can be overridden before choosing
   "patch" or "diff" commands in "git add -i".

Because we generate diff once, and then let the end-user dice and slice freely, without keeping track of the correspondence between what the original diff looked like and the current diff that is a result of end-user dicing and slicing, I think extending the context length on demand (i.e. "I started an 'add -p' session, chose a few hunks, edited a handful hunks, and then realized that this single hunk I want to see a bit more context") is _significantly_ harder. The current code structure is simply not designed for it.

It would take a significant rewrite to allow you to say "OK, let me regenerate the diff with wider context (this is the easy part) and find the hunk with larger context that corresponds with the hunk you are talking about (harder)".