add -p: make the beginning of the hunk easier to see
PATCH 1/1 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.
--- git-add--interactive.perl | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
git-add--interactive.perl +2 -0
@@ -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);
Signature · 1 line
1.7.0
git-add--interactive.perl sub patch_update_file { · line 1446
Quoted 13 lines · Björn Gustavsson
git-add--interactive.perl +2
-0@@ -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
Quoted 14 lines · Jeff King
Quoted 12 lines · Björn Gustavsson
git-add--interactive.perl +2
-0@@ -1439,6 +1439,8 @@ sub patch_update_file { !defined $hunk[$ix]{USE}); } } + } continue { + print "\n" x 4, '=' x 72, "\n"; }
Quoted 3 lines
git-add--interactive.perl sub patch_update_file { · line 1446
Quoted 1 line
git-add--interactive.perl +0
-0@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 <[email protected]>:
Quoted 7 lines · Jeff King
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.
Signature · 1 line
Björn Gustavsson, Erlang/OTP, Ericsson AB
2010/2/13 Jeff King <[email protected]>:
Quoted 4 lines · Björn Gustavsson
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.
Quoted 1 line
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.
Signature · 1 line
Björn Gustavsson, Erlang/OTP, Ericsson AB
2010/2/13 Björn Gustavsson <[email protected]>:
Quoted 7 lines
2010/2/13 Jeff King <[email protected]>:
Quoted 4 lines · Björn Gustavsson
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).
Signature · 1 line
Björn Gustavsson, Erlang/OTP, Ericsson AB
Quoted 3 lines · Björn Gustavsson
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.
Quoted 4 lines
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 <[email protected]>:
Quoted 3 lines · Björn Gustavsson
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!
Signature · 1 line
Björn Gustavsson, Erlang/OTP, Ericsson AB
Quoted 3 lines · Björn Gustavsson
2010/2/13 Jeff King <[email protected]>:
Quoted 2 lines · Björn Gustavsson
If you are using color.interactive (or color.ui), that should already
be
Quoted 8 lines
Quoted 1 line
"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.
Quoted 5 lines
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.
Signature · 1 line
Julian
2010/2/13 Julian Phillips <[email protected]>:
Quoted 6 lines
Quoted 3 lines
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:
Quoted 8 lines
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.
Signature · 1 line
Björn Gustavsson, Erlang/OTP, Ericsson AB