Jeff King <peff@xxxxxxxx> writes:
> However, I'm not sure I would trust my regex to actually get all of the
> changes needed for the refactoring (e.g., there might be nearby hunks
> related to the refactoring that are not specifically in the same hunk as
> the word "foo"). So I tend to just "git add -p" and flip through the
> changes manually.
Yes, that is a valid concern.
> You can already skip around in the hunk list using "/regex". Might that
> be enough for you? I think you're stuck typing "/yoursearch" over and
> over, though. It would be nice if doing just "/" would search again for
> the previous regex.
Yes, I think that makes a lot more sense than the current "Ah, empty? ask
from the terminal" behaviour.
git-add--interactive.perl | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 8f0839d..0b6f8a6 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1257,7 +1257,7 @@ sub display_hunks {
sub patch_update_file {
my $quit = 0;
- my ($ix, $num);
+ my ($ix, $num, $last_search_string);
my $path = shift;
my ($head, @hunk) = parse_diff($path);
($head, my $mode, my $deletion) = parse_diff_header($head);
@@ -1395,11 +1395,12 @@ sub patch_update_file {
}
elsif ($line =~ m|^/(.*)|) {
my $regex = $1;
- if ($1 eq "") {
- print colored $prompt_color, "search for regex? ";
- $regex = <STDIN>;
- if (defined $regex) {
- chomp $regex;
+ if ($regex eq "") {
+ if ($last_search_string) {
+ $regex = $last_search_string;
+ } else {
+ error_msg "Need a regexp to search\n";
+ next;
}
}
my $search_string;
@@ -1412,6 +1413,7 @@ sub patch_update_file {
error_msg "Malformed search regexp $exp: $err\n";
next;
}
+ $last_search_string = $regex;
my $iy = $ix;
while (1) {
my $text = join ("", @{$hunk[$iy]{TEXT}});
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html