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

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 <redacted>
---
 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

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? Or is it
that small hunks tend to confused with the previous hunk?

-Peff

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:

quoted

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

2010/2/13 Jeff King [off-list ref]:

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

2010/2/13 Jeff King [off-list ref]:

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

2010/2/13 Björn Gustavsson [off-list ref]:

2010/2/13 Jeff King [off-list ref]:

quoted

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

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

2010/2/13 Jeff King [off-list ref]:

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

On Sat, 13 Feb 2010 15:34:00 +0100, Björn Gustavsson
[off-list ref] wrote:

2010/2/13 Jeff King [off-list ref]:

quoted

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

quoted

"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

2010/2/13 Julian Phillips [off-list ref]:

quoted

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