[PATCH] add -p: make the beginning of the hunk easier to see

[PATCH] add -p: make the beginning of the hunk easier to see

[Björn Gustavsson]

When using "git add -p" to selectively add hunks, I find
it hard to quickly see where the current hunk starts and
the previous stops, because the new hunk starts right
after the action prompt for the previous hunk.

Facilitate easy scanning for the beginning of the current
hunk by adding some blank lines and a line of equal
signs before the current hunk.

Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
 git-add--interactive.perl |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index cd43c34..4eb7c7c 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1439,6 +1439,8 @@ sub patch_update_file {
 					 !defined $hunk[$ix]{USE});
 			}
 		}
+	} continue {
+		print "\n" x 4, '=' x 72, "\n";
 	}
 
 	@hunk = coalesce_overlapping_hunks(@hunk);
-- 
1.7.0

Re: [PATCH] add -p: make the beginning of the hunk easier to see

[Jeff King]

On Sat, Feb 13, 2010 at 12:07:51PM +0100, Björn Gustavsson wrote:

> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index cd43c34..4eb7c7c 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -1439,6 +1439,8 @@ sub patch_update_file {
>  					 !defined $hunk[$ix]{USE});
>  			}
>  		}
> +	} continue {
> +		print "\n" x 4, '=' x 72, "\n";
>  	}
>  
>  	@hunk = coalesce_overlapping_hunks(@hunk);

Wow, I find this terrifically ugly. I guess you don't use
color.interactive, which will output a colored hunk header? Or is it
that small hunks tend to confused with the previous hunk?

-Peff

Re: [PATCH] add -p: make the beginning of the hunk easier to see

[Jeff King]

On Sat, Feb 13, 2010 at 06:23:43AM -0500, Jeff King wrote:

> On Sat, Feb 13, 2010 at 12:07:51PM +0100, Björn Gustavsson wrote:
> 
> > diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> > index cd43c34..4eb7c7c 100755
> > --- a/git-add--interactive.perl
> > +++ b/git-add--interactive.perl
> > @@ -1439,6 +1439,8 @@ sub patch_update_file {
> >  					 !defined $hunk[$ix]{USE});
> >  			}
> >  		}
> > +	} continue {
> > +		print "\n" x 4, '=' x 72, "\n";
> >  	}
> >  
> >  	@hunk = coalesce_overlapping_hunks(@hunk);
> 
> Wow, I find this terrifically ugly. I guess you don't use

Side note. Even if we did want to do something like this, your
implementation is probably not the right way. It will print the huge
"===" separator even after the last hunk. You would want to keep a
"$shown_any" variable and output the separator before showing a hunk
instead.

-Peff

Re: [PATCH] add -p: make the beginning of the hunk easier to see

[Björn Gustavsson]

2010/2/13 Jeff King <peff@peff.net>:
> On Sat, Feb 13, 2010 at 06:23:43AM -0500, Jeff King wrote:

> Side note. Even if we did want to do something like this, your
> implementation is probably not the right way. It will print the huge
> "===" separator even after the last hunk. You would want to keep a
> "$shown_any" variable and output the separator before showing a hunk
> instead.

OK. I can fix that if there seems to be any interest to include it.

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB

Re: [PATCH] add -p: make the beginning of the hunk easier to see

[Björn Gustavsson]

2010/2/13 Jeff King <peff@peff.net>:
> On Sat, Feb 13, 2010 at 12:07:51PM +0100, Björn Gustavsson wrote:
>
> Wow, I find this terrifically ugly. I guess you don't use
> color.interactive, which will output a colored hunk header?

I do use color.interactive, but I didn't find that distinctive enough.

> Or is it that small hunks tend to confused with the previous hunk?

Yes, my hunks were small and I wanted to go through them
really quickly, but still be sure that I did correctly, so I found that
I spent a lot of time making sure that I have found the beginning
of the current hunk.

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB

Re: [PATCH] add -p: make the beginning of the hunk easier to see

[Björn Gustavsson]

2010/2/13 Björn Gustavsson <bgustavsson@gmail.com>:
> 2010/2/13 Jeff King <peff@peff.net>:
>> On Sat, Feb 13, 2010 at 12:07:51PM +0100, Björn Gustavsson wrote:
>>
>> Wow, I find this terrifically ugly. I guess you don't use
>> color.interactive, which will output a colored hunk header?
>
> I do use color.interactive, but I didn't find that distinctive enough.

As an alternative to my patch, the color coding could be changed.
The beginning of a chunk is now marked with a faint bluish color (the part
that looks like "@@ -42,9 +43,8 @@").

Giving the "Stage this hunk..." prompt some noticeable color (such as red),
could make it easier to the see beginning of the hunk. Or
simply doing a form-feed (but I suppose not everyone would
like that).

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB

Re: [PATCH] add -p: make the beginning of the hunk easier to see

[Jeff King]

On Sat, Feb 13, 2010 at 12:42:56PM +0100, Björn Gustavsson wrote:

> As an alternative to my patch, the color coding could be changed.
> The beginning of a chunk is now marked with a faint bluish color (the part
> that looks like "@@ -42,9 +43,8 @@").

You can tweak that color with the color.diff.frag config variable.

> Giving the "Stage this hunk..." prompt some noticeable color (such as red),
> could make it easier to the see beginning of the hunk. Or
> simply doing a form-feed (but I suppose not everyone would
> like that).

If you are using color.interactive (or color.ui), that should already be
"bold blue". You can change it to red with color.interactive.prompt.

Personally, I prefer the color approach. It's less ugly looking (IMHO),
and it is configurable, so people who don't like it don't have to see
it. It's also already implemented, though one could perhaps make an
argument for changing the defaults.

-Peff

Re: [PATCH] add -p: make the beginning of the hunk easier to see

[Björn Gustavsson]

2010/2/13 Jeff King <peff@peff.net>:
> On Sat, Feb 13, 2010 at 12:42:56PM +0100, Björn Gustavsson wrote:
> If you are using color.interactive (or color.ui), that should already be
> "bold blue". You can change it to red with color.interactive.prompt.

Oops! Turned out I only had colors for "diff", "status", and "branch",
so the prompt had had no color. I configured my color settings the
day I started using git last spring (according to some tutorial or
getting started document) and haven't looked at the color
settings since.

Now it looks much better.

Personally, I would prefer if more colors were turned on by
default, or if there were a master setting to turn on all colors
at once.

Thanks for the help!

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB

Re: [PATCH] add -p: make the beginning of the hunk easier to see

[Julian Phillips]

On Sat, 13 Feb 2010 15:34:00 +0100, Björn Gustavsson
<bgustavsson@gmail.com> wrote:
> 2010/2/13 Jeff King <peff@peff.net>:
>> On Sat, Feb 13, 2010 at 12:42:56PM +0100, Björn Gustavsson wrote:
>> If you are using color.interactive (or color.ui), that should already
be
>> "bold blue". You can change it to red with color.interactive.prompt.
> 
> Oops! Turned out I only had colors for "diff", "status", and "branch",
> so the prompt had had no color. I configured my color settings the
> day I started using git last spring (according to some tutorial or
> getting started document) and haven't looked at the color
> settings since.
> 
> Now it looks much better.
> 
> Personally, I would prefer if more colors were turned on by
> default, or if there were a master setting to turn on all colors
> at once.

quoting man git-config:

       color.ui
           When set to always, always use colors in all git commands which
are
           capable of colored output. When false (or never), never. When
set
           to true or auto, use colors only when the output is to the
           terminal. When more specific variables of color.* are set, they
           always take precedence over this setting. Defaults to false.

-- 
Julian

Re: [PATCH] add -p: make the beginning of the hunk easier to see

[Björn Gustavsson]

2010/2/13 Julian Phillips <julian@quantumfyre.co.uk>:
>> Personally, I would prefer if more colors were turned on by
>> default, or if there were a master setting to turn on all colors
>> at once.
>
> quoting man git-config:
>
>       color.ui
>           When set to always, always use colors in all git commands which
> are
>           capable of colored output. When false (or never), never. When
> set
>           to true or auto, use colors only when the output is to the
>           terminal. When more specific variables of color.* are set, they
>           always take precedence over this setting. Defaults to false.

Thanks!

I have learned a lot today.

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB