Better visual separation of hunks in `git add -p`

Better visual separation of hunks in `git add -p`

[Eugenio Bargiacchi]

Hello,

I'm looking for a way to print some sort of separator between hunks
when running `git add -p`, as I have a bit of trouble detecting when
the previous hunk begins and the current one starts. Being able to
print an empty line or a couple lines filled with "=======" would
really help me out.

There seems to be a StackOverflow post with a similar request but
unfortunately no answers:
https://stackoverflow.com/questions/68534891/insert-blank-lines-between-git-add-patch-prompts

Thanks in advance for any help.
Best,
Eugenio

Re: Better visual separation of hunks in `git add -p`

[Junio C Hamano]

Eugenio Bargiacchi <svalorzen@gmail.com> writes:

> I'm looking for a way to print some sort of separator between hunks
> when running `git add -p`, as I have a bit of trouble detecting when
> the previous hunk begins and the current one starts. Being able to
> print an empty line or a couple lines filled with "=======" would
> really help me out.

Hmph, my hope when I designed that particular UI was that the
command prompt for the previous interaction followed by the hunk
header of the current hunk would give us clear enough separation.

For example, after answering "n" to the prompt for the previous
hunk, we'd see

    ...
    +   (merge bff85a338c bl/doc-key-val-sep-fix later to maint).
    +
      * Other code cleanup, docfix, build fix, etc.
        (merge f0e578c69c rs/use-xstrncmpz later to maint).
        (merge 83e6eb7d7a ba/credential-test-clean-fix later to maint).
    (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? n
    @@ -233,3 +245,6 @@ Fixes since v2.44
        (merge 781fb7b4c2 as/option-names-in-messages later to maint).
        (merge 51d41dc243 jk/doc-remote-helpers-markup-fix later to maint).
        (merge e1aaf309db pb/ci-win-artifact-names-fix later to maint).
    +   (merge ad538c61da jc/index-pack-fsck-levels later to maint).
    +   (merge 67471bc704 ja/doc-formatting-fix later to maint).
    ...
    (2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]?

The '@' (the first character of the hunk header line for the current
hunk) and "(1/2" are surrounded by lines that begin with a space,
and the hope was that it was sufficient "separator" already.

These days (long after I stopped mucking with the interactive add
code actively), the prompt line is painted in prompt_color (you can
tweak it with the color.interactive.prompt configuration variable,
it defaults to BOLD BLUE) while the first part of the hunk header
line is painted in the fraginfo color (default CYAN), which should
give you even more visual distinction.

Perhaps

    [color "interactive"]
	prompt = bold red reverse

would be sufficient?  I dunno.

Re: Better visual separation of hunks in `git add -p`

[Eugenio Bargiacchi]

Thank you for the suggestion, it already helps a bit.

The problem only using indentations as a visual separator, for me, is
that if the code snipped already has indentations, then the ones added
by 'git add' do not really stand up, and instead become part of a very
long uninterrupted stream of text. In addition to this, given that the
snippet is colored, the result is a very bright and flashy wall of
text that can be a bit much to sift through (were it all the same
color it would be worse though). Being able to break up the hunks
visually with some whitespace would really go a long way.

In any case, for now I'll try to pick up the most obnoxious colors for
the prompt that I can :) Hopefully in the future this will be an
available option for difficult people like me.

On Thu, 28 Mar 2024 at 17:50, Junio C Hamano <gitster@pobox.com> wrote:
>
> Eugenio Bargiacchi <svalorzen@gmail.com> writes:
>
> > I'm looking for a way to print some sort of separator between hunks
> > when running `git add -p`, as I have a bit of trouble detecting when
> > the previous hunk begins and the current one starts. Being able to
> > print an empty line or a couple lines filled with "=======" would
> > really help me out.
>
> Hmph, my hope when I designed that particular UI was that the
> command prompt for the previous interaction followed by the hunk
> header of the current hunk would give us clear enough separation.
>
> For example, after answering "n" to the prompt for the previous
> hunk, we'd see
>
>     ...
>     +   (merge bff85a338c bl/doc-key-val-sep-fix later to maint).
>     +
>       * Other code cleanup, docfix, build fix, etc.
>         (merge f0e578c69c rs/use-xstrncmpz later to maint).
>         (merge 83e6eb7d7a ba/credential-test-clean-fix later to maint).
>     (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? n
>     @@ -233,3 +245,6 @@ Fixes since v2.44
>         (merge 781fb7b4c2 as/option-names-in-messages later to maint).
>         (merge 51d41dc243 jk/doc-remote-helpers-markup-fix later to maint).
>         (merge e1aaf309db pb/ci-win-artifact-names-fix later to maint).
>     +   (merge ad538c61da jc/index-pack-fsck-levels later to maint).
>     +   (merge 67471bc704 ja/doc-formatting-fix later to maint).
>     ...
>     (2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]?
>
> The '@' (the first character of the hunk header line for the current
> hunk) and "(1/2" are surrounded by lines that begin with a space,
> and the hope was that it was sufficient "separator" already.
>
> These days (long after I stopped mucking with the interactive add
> code actively), the prompt line is painted in prompt_color (you can
> tweak it with the color.interactive.prompt configuration variable,
> it defaults to BOLD BLUE) while the first part of the hunk header
> line is painted in the fraginfo color (default CYAN), which should
> give you even more visual distinction.
>
> Perhaps
>
>     [color "interactive"]
>         prompt = bold red reverse
>
> would be sufficient?  I dunno.
>

Re: Better visual separation of hunks in `git add -p`

[Dragan Simic]

On 2024-03-28 17:50, Junio C Hamano wrote:
> Eugenio Bargiacchi <svalorzen@gmail.com> writes:
> 
>> I'm looking for a way to print some sort of separator between hunks
>> when running `git add -p`, as I have a bit of trouble detecting when
>> the previous hunk begins and the current one starts. Being able to
>> print an empty line or a couple lines filled with "=======" would
>> really help me out.
> 
> Hmph, my hope when I designed that particular UI was that the
> command prompt for the previous interaction followed by the hunk
> header of the current hunk would give us clear enough separation.
> 
> For example, after answering "n" to the prompt for the previous
> hunk, we'd see
> 
>     ...
>     +   (merge bff85a338c bl/doc-key-val-sep-fix later to maint).
>     +
>       * Other code cleanup, docfix, build fix, etc.
>         (merge f0e578c69c rs/use-xstrncmpz later to maint).
>         (merge 83e6eb7d7a ba/credential-test-clean-fix later to maint).
>     (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? n
>     @@ -233,3 +245,6 @@ Fixes since v2.44
>         (merge 781fb7b4c2 as/option-names-in-messages later to maint).
>         (merge 51d41dc243 jk/doc-remote-helpers-markup-fix later to 
> maint).
>         (merge e1aaf309db pb/ci-win-artifact-names-fix later to maint).
>     +   (merge ad538c61da jc/index-pack-fsck-levels later to maint).
>     +   (merge 67471bc704 ja/doc-formatting-fix later to maint).
>     ...
>     (2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]?
> 
> The '@' (the first character of the hunk header line for the current
> hunk) and "(1/2" are surrounded by lines that begin with a space,
> and the hope was that it was sufficient "separator" already.
> 
> These days (long after I stopped mucking with the interactive add
> code actively), the prompt line is painted in prompt_color (you can
> tweak it with the color.interactive.prompt configuration variable,
> it defaults to BOLD BLUE) while the first part of the hunk header
> line is painted in the fraginfo color (default CYAN), which should
> give you even more visual distinction.
> 
> Perhaps
> 
>     [color "interactive"]
> 	prompt = bold red reverse
> 
> would be sufficient?  I dunno.

Here's a possible solution, or better said a new configuration option,
which I've been thinking about for a while...  When running "add -p",
displayed chunks can sometimes become confusing or a bit hard on the
eyes, but simply clearing the screen _before_ displaying any new step
(i.e. a new chunk, interactive help, etc.) could make it much easier
on the eyes.  It would be a new option, of course.

Thoughts?

Re: Better visual separation of hunks in `git add -p`

[Junio C Hamano]

Dragan Simic <dsimic@manjaro.org> writes:

> Here's a possible solution, or better said a new configuration option,
> which I've been thinking about for a while...  When running "add -p",
> displayed chunks can sometimes become confusing or a bit hard on the
> eyes, but simply clearing the screen _before_ displaying any new step
> (i.e. a new chunk, interactive help, etc.) could make it much easier
> on the eyes.  It would be a new option, of course.

Or your 'p' option can have a 'P' variant that clears before prints.
I have this feeling that even those who want clearing of the screen,
they do not want it always on, when many of their hunks are 7 lines
long.

Re: Better visual separation of hunks in `git add -p`

[Dragan Simic]

On 2024-03-28 19:21, Junio C Hamano wrote:
> Dragan Simic <dsimic@manjaro.org> writes:
> 
>> Here's a possible solution, or better said a new configuration option,
>> which I've been thinking about for a while...  When running "add -p",
>> displayed chunks can sometimes become confusing or a bit hard on the
>> eyes, but simply clearing the screen _before_ displaying any new step
>> (i.e. a new chunk, interactive help, etc.) could make it much easier
>> on the eyes.  It would be a new option, of course.
> 
> Or your 'p' option can have a 'P' variant that clears before prints.
> I have this feeling that even those who want clearing of the screen,
> they do not want it always on, when many of their hunks are 7 lines
> long.

That would be even better.  Though, would adding new short command-line
option to git-add be frowned upon?

Re: Better visual separation of hunks in `git add -p`

[Eugenio Bargiacchi]

> Here's a possible solution, or better said a new configuration option,
> which I've been thinking about for a while...  When running "add -p",
> displayed chunks can sometimes become confusing or a bit hard on the
> eyes, but simply clearing the screen _before_ displaying any new step
> (i.e. a new chunk, interactive help, etc.) could make it much easier
> on the eyes.  It would be a new option, of course.

In my head, an option to print an arbitrary string would be amazing,
since then if wanted one can print a special character that clears the
screen, or simply add some space, or something else.

On Thu, 28 Mar 2024 at 19:29, Dragan Simic <dsimic@manjaro.org> wrote:
>
> On 2024-03-28 19:21, Junio C Hamano wrote:
> > Dragan Simic <dsimic@manjaro.org> writes:
> >
> >> Here's a possible solution, or better said a new configuration option,
> >> which I've been thinking about for a while...  When running "add -p",
> >> displayed chunks can sometimes become confusing or a bit hard on the
> >> eyes, but simply clearing the screen _before_ displaying any new step
> >> (i.e. a new chunk, interactive help, etc.) could make it much easier
> >> on the eyes.  It would be a new option, of course.
> >
> > Or your 'p' option can have a 'P' variant that clears before prints.
> > I have this feeling that even those who want clearing of the screen,
> > they do not want it always on, when many of their hunks are 7 lines
> > long.
>
> That would be even better.  Though, would adding new short command-line
> option to git-add be frowned upon?

Re: Better visual separation of hunks in `git add -p`

[Dragan Simic]

On 2024-03-28 20:01, Eugenio Bargiacchi wrote:
>> Here's a possible solution, or better said a new configuration option,
>> which I've been thinking about for a while...  When running "add -p",
>> displayed chunks can sometimes become confusing or a bit hard on the
>> eyes, but simply clearing the screen _before_ displaying any new step
>> (i.e. a new chunk, interactive help, etc.) could make it much easier
>> on the eyes.  It would be a new option, of course.
> 
> In my head, an option to print an arbitrary string would be amazing,
> since then if wanted one can print a special character that clears the
> screen, or simply add some space, or something else.

Huh, letting the users handle screen clearing that way could be rather
problematic, because different terminals may do it differently.

> On Thu, 28 Mar 2024 at 19:29, Dragan Simic <dsimic@manjaro.org> wrote:
>> 
>> On 2024-03-28 19:21, Junio C Hamano wrote:
>> > Dragan Simic <dsimic@manjaro.org> writes:
>> >
>> >> Here's a possible solution, or better said a new configuration option,
>> >> which I've been thinking about for a while...  When running "add -p",
>> >> displayed chunks can sometimes become confusing or a bit hard on the
>> >> eyes, but simply clearing the screen _before_ displaying any new step
>> >> (i.e. a new chunk, interactive help, etc.) could make it much easier
>> >> on the eyes.  It would be a new option, of course.
>> >
>> > Or your 'p' option can have a 'P' variant that clears before prints.
>> > I have this feeling that even those who want clearing of the screen,
>> > they do not want it always on, when many of their hunks are 7 lines
>> > long.
>> 
>> That would be even better.  Though, would adding new short 
>> command-line
>> option to git-add be frowned upon?

Re: Better visual separation of hunks in `git add -p`

[Eugenio Bargiacchi]

But then each can configure it specifically for their terminal, no? Or
are you afraid that a user may use different terminals at the same
time, so the same config would be applied, so it would not work? In
any case, my suggestion was aiming mainly to avoid having to add
multiple options while allowing to freely customize the separators,
but if that will not work in general to clear, that makes sense as
well.

On Thu, 28 Mar 2024 at 20:04, Dragan Simic <dsimic@manjaro.org> wrote:
>
> On 2024-03-28 20:01, Eugenio Bargiacchi wrote:
> >> Here's a possible solution, or better said a new configuration option,
> >> which I've been thinking about for a while...  When running "add -p",
> >> displayed chunks can sometimes become confusing or a bit hard on the
> >> eyes, but simply clearing the screen _before_ displaying any new step
> >> (i.e. a new chunk, interactive help, etc.) could make it much easier
> >> on the eyes.  It would be a new option, of course.
> >
> > In my head, an option to print an arbitrary string would be amazing,
> > since then if wanted one can print a special character that clears the
> > screen, or simply add some space, or something else.
>
> Huh, letting the users handle screen clearing that way could be rather
> problematic, because different terminals may do it differently.
>
> > On Thu, 28 Mar 2024 at 19:29, Dragan Simic <dsimic@manjaro.org> wrote:
> >>
> >> On 2024-03-28 19:21, Junio C Hamano wrote:
> >> > Dragan Simic <dsimic@manjaro.org> writes:
> >> >
> >> >> Here's a possible solution, or better said a new configuration option,
> >> >> which I've been thinking about for a while...  When running "add -p",
> >> >> displayed chunks can sometimes become confusing or a bit hard on the
> >> >> eyes, but simply clearing the screen _before_ displaying any new step
> >> >> (i.e. a new chunk, interactive help, etc.) could make it much easier
> >> >> on the eyes.  It would be a new option, of course.
> >> >
> >> > Or your 'p' option can have a 'P' variant that clears before prints.
> >> > I have this feeling that even those who want clearing of the screen,
> >> > they do not want it always on, when many of their hunks are 7 lines
> >> > long.
> >>
> >> That would be even better.  Though, would adding new short
> >> command-line
> >> option to git-add be frowned upon?

Re: Better visual separation of hunks in `git add -p`

[Dragan Simic]

On 2024-03-28 20:08, Eugenio Bargiacchi wrote:
> But then each can configure it specifically for their terminal, no? Or
> are you afraid that a user may use different terminals at the same
> time, so the same config would be applied, so it would not work? In
> any case, my suggestion was aiming mainly to avoid having to add
> multiple options while allowing to freely customize the separators,
> but if that will not work in general to clear, that makes sense as
> well.

Of course, users could pick the right escape sequences for their
terminals, but as you already noted, the same configurations could
end up being used on different terminals.  For example, even SSHing
into a machine using a different SSH client could lead to a mess.


> On Thu, 28 Mar 2024 at 20:04, Dragan Simic <dsimic@manjaro.org> wrote:
>> 
>> On 2024-03-28 20:01, Eugenio Bargiacchi wrote:
>> >> Here's a possible solution, or better said a new configuration option,
>> >> which I've been thinking about for a while...  When running "add -p",
>> >> displayed chunks can sometimes become confusing or a bit hard on the
>> >> eyes, but simply clearing the screen _before_ displaying any new step
>> >> (i.e. a new chunk, interactive help, etc.) could make it much easier
>> >> on the eyes.  It would be a new option, of course.
>> >
>> > In my head, an option to print an arbitrary string would be amazing,
>> > since then if wanted one can print a special character that clears the
>> > screen, or simply add some space, or something else.
>> 
>> Huh, letting the users handle screen clearing that way could be rather
>> problematic, because different terminals may do it differently.
>> 
>> > On Thu, 28 Mar 2024 at 19:29, Dragan Simic <dsimic@manjaro.org> wrote:
>> >>
>> >> On 2024-03-28 19:21, Junio C Hamano wrote:
>> >> > Dragan Simic <dsimic@manjaro.org> writes:
>> >> >
>> >> >> Here's a possible solution, or better said a new configuration option,
>> >> >> which I've been thinking about for a while...  When running "add -p",
>> >> >> displayed chunks can sometimes become confusing or a bit hard on the
>> >> >> eyes, but simply clearing the screen _before_ displaying any new step
>> >> >> (i.e. a new chunk, interactive help, etc.) could make it much easier
>> >> >> on the eyes.  It would be a new option, of course.
>> >> >
>> >> > Or your 'p' option can have a 'P' variant that clears before prints.
>> >> > I have this feeling that even those who want clearing of the screen,
>> >> > they do not want it always on, when many of their hunks are 7 lines
>> >> > long.
>> >>
>> >> That would be even better.  Though, would adding new short
>> >> command-line
>> >> option to git-add be frowned upon?

Re: Better visual separation of hunks in `git add -p`

[Junio C Hamano]

Dragan Simic <dsimic@manjaro.org> writes:

> Of course, users could pick the right escape sequences for their
> terminals, but as you already noted, the same configurations could
> end up being used on different terminals.  For example, even SSHing
> into a machine using a different SSH client could lead to a mess.

There is a separate discussion of conditional configuration based on
environment variable settings, e.g.

    [includeIf "env:TERM:vt100"]
	path = ~/.git-config-bits/vt100

where the named file might have

    [prompt] prefix = "\033[H\033[J"

so it is certainly doable.

It is a different story if doing so is sensible, of course.

Re: Better visual separation of hunks in `git add -p`

[Dragan Simic]

On 2024-03-28 21:43, Junio C Hamano wrote:
> Dragan Simic <dsimic@manjaro.org> writes:
> 
>> Of course, users could pick the right escape sequences for their
>> terminals, but as you already noted, the same configurations could
>> end up being used on different terminals.  For example, even SSHing
>> into a machine using a different SSH client could lead to a mess.
> 
> There is a separate discussion of conditional configuration based on
> environment variable settings, e.g.
> 
>     [includeIf "env:TERM:vt100"]
> 	path = ~/.git-config-bits/vt100
> 
> where the named file might have
> 
>     [prompt] prefix = "\033[H\033[J"
> 
> so it is certainly doable.
> 
> It is a different story if doing so is sensible, of course.

Quite frankly, I think that would be like opening a can of worms.
In other words, if we end up implementing support for the "add -P"
prefix, allowing the users to do whatever they want with the prefixes
would surely be fine, but only if we implement "add -P" at the same
time, to already provide a reliable and simple way for clearing the
screen.

Re: Better visual separation of hunks in `git add -p`

[Eugenio Bargiacchi]

It seems to me that the two options are orthogonal: allowing the user
to add an arbitrary prefix is not a block for allowing the user to
clear the screen or vice-versa. If anything, the arbitrary prefix
seems the more general flag to me as it at least offers a way (however
unportable) to perform a clear. So saying that if we do not allow the
user to clear the screen then it is not fine to add arbitrary prefixes
seems strange.

On Thu, 28 Mar 2024 at 22:19, Dragan Simic <dsimic@manjaro.org> wrote:
>
> On 2024-03-28 21:43, Junio C Hamano wrote:
> > Dragan Simic <dsimic@manjaro.org> writes:
> >
> >> Of course, users could pick the right escape sequences for their
> >> terminals, but as you already noted, the same configurations could
> >> end up being used on different terminals.  For example, even SSHing
> >> into a machine using a different SSH client could lead to a mess.
> >
> > There is a separate discussion of conditional configuration based on
> > environment variable settings, e.g.
> >
> >     [includeIf "env:TERM:vt100"]
> >       path = ~/.git-config-bits/vt100
> >
> > where the named file might have
> >
> >     [prompt] prefix = "\033[H\033[J"
> >
> > so it is certainly doable.
> >
> > It is a different story if doing so is sensible, of course.
>
> Quite frankly, I think that would be like opening a can of worms.
> In other words, if we end up implementing support for the "add -P"
> prefix, allowing the users to do whatever they want with the prefixes
> would surely be fine, but only if we implement "add -P" at the same
> time, to already provide a reliable and simple way for clearing the
> screen.

Re: Better visual separation of hunks in `git add -p`

[Dragan Simic]

On 2024-03-28 22:43, Eugenio Bargiacchi wrote:
> It seems to me that the two options are orthogonal: allowing the user
> to add an arbitrary prefix is not a block for allowing the user to
> clear the screen or vice-versa. If anything, the arbitrary prefix
> seems the more general flag to me as it at least offers a way (however
> unportable) to perform a clear. So saying that if we do not allow the
> user to clear the screen then it is not fine to add arbitrary prefixes
> seems strange.

Well, it all depends on one's perspective.  To me more precise, I don't
care about the prefixes because I've never wanted them, but I'd like to 
be
able to clear the screen.  Thus, from my viewpoint, which is presumably
shared with other users, forcing me to use the prefix to be able to 
clear
the screen, and to use it in a messy way, makes little sense.

I hope this makes my perspective mroe clear.


> On Thu, 28 Mar 2024 at 22:19, Dragan Simic <dsimic@manjaro.org> wrote:
>> 
>> On 2024-03-28 21:43, Junio C Hamano wrote:
>> > Dragan Simic <dsimic@manjaro.org> writes:
>> >
>> >> Of course, users could pick the right escape sequences for their
>> >> terminals, but as you already noted, the same configurations could
>> >> end up being used on different terminals.  For example, even SSHing
>> >> into a machine using a different SSH client could lead to a mess.
>> >
>> > There is a separate discussion of conditional configuration based on
>> > environment variable settings, e.g.
>> >
>> >     [includeIf "env:TERM:vt100"]
>> >       path = ~/.git-config-bits/vt100
>> >
>> > where the named file might have
>> >
>> >     [prompt] prefix = "\033[H\033[J"
>> >
>> > so it is certainly doable.
>> >
>> > It is a different story if doing so is sensible, of course.
>> 
>> Quite frankly, I think that would be like opening a can of worms.
>> In other words, if we end up implementing support for the "add -P"
>> prefix, allowing the users to do whatever they want with the prefixes
>> would surely be fine, but only if we implement "add -P" at the same
>> time, to already provide a reliable and simple way for clearing the
>> screen.