Add / command in add --patch (feature request)

This sequence of 2 patches adds a '/' command to add --patch that allows the user to search for a hunk that matches a regex, and deals with j,k slightly more gracefully. (Rather than printing the help menu if k is invalid, it will print
a relevant error message.)

This is naive, and it is easy for an invalid search string to cause a perl error.

I think it could be useful functionality to make robust.

(Please CC me in any response)

---
 git-add--interactive.perl |   26 ++++++++++++++++++++++----
 1 files changed, 22 insertions(+), 4 deletions(-)

index b0223c3..7ad4ee0 100755
@@ -876,12 +876,14 @@ sub patch_update_file {
 
 	$num = scalar @hunk;
 	$ix = 0;
+	my $search_s; # User entered string to match a hunk.
 
 	while (1) {
 		my ($prev, $next, $other, $undecided, $i);
 		$other = '';
 
 		if ($num <= $ix) {
+			$search_s = 0;
 			$ix = 0;
 		}
 		for ($i = 0; $i < $ix; $i++) {

@@ -916,11 +918,24 @@ sub patch_update_file {
 			$other .= '/s';
 		}
 		$other .= '/e';
-		for (@{$hunk[$ix]{DISPLAY}}) {
-			print;
+
+		my $line;
+		if( $search_s ) {
+			my $text = join( "", @{$hunk[$ix]{DISPLAY}} );
+			if( $text !~ $search_s ) {
+				$line = "n\n";
+			} else {
+				print $text;
+			}
+		} else {
+			for (@{$hunk[$ix]{DISPLAY}}) {
+				print;
+			}
+		}
+		if (!$line) {
+			print colored $prompt_color, "Stage this hunk [y/n/a/d///$other/?]? ";
+			$line = <STDIN>;
 		}
-		print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
-		my $line = <STDIN>;
 		if ($line) {
 			if ($line =~ /^y/i) {
 				$hunk[$ix]{USE} = 1;

@@ -946,6 +961,9 @@ sub patch_update_file {
 				}
 				next;
 			}
+			elsif ($line =~ m|^/(.*)|) {
+				$search_s = $1;
+			}
 			elsif ($other =~ /K/ && $line =~ /^K/) {
 				$ix--;
 				next;

1.6.0.4.781.gf2070.dirty


-- 
William Pursell

Use of eval is a good way to protect against this kind of breakage, but it should be done close to where the string is given by the user, perhaps in here:

+ elsif ($line =~ m|^/(.*)|) {
+ $search_s = $1;
+ }

Something like...

	elsif ($line =~ m|^/(.*)|) {
        	$search_string = $1;
                eval {
                	$search_string =~ /$search_string/;
		};
                if ($@) {
                	print STDERR "Regexp error in $search_string: $@";
			next;
		}
	...

Thanks. The second set of patches that I just sent up is fatally flawed--by changing to skip unmatched hunks instead of deselecting them, it enters a loop if no hunks match.

Before working on patches, I'd like some ideas on functionality:

1) If a hunk doesn't match, should it be as if the user selected 'n', or 'j'?
2) If no hunks match it is easiest to simply move to the last hunk and display it, but I'm not sure that is acceptable. Probably better to return to the hunk that was being viewed when the search string is entered, but that seems to require some restructuring of the code. What would be the preferred behavior?

William Pursell

Is it an option to tell "nothing matched", stay at the same hunk and ask the user to make the choice again?

Hi,

I find these references to j and k not only confusing, but slightly unnerving. Care to be a bit more explicit?

Always on this list; we respect netiquette.

Ciao,
Dscho