WG: [git-for-windows/git] log -L/<regex>/,+1 not accepted (#1856)

WG: [git-for-windows/git] log -L/<regex>/,+1 not accepted (#1856)

[Peter.Dolland]

Please see my original observation below.
Is it possible, to extend the git-log syntax in the way, that it accepts the short -L option (without :file) of blame in unique cases (only one file is logged or respectively the -L expression may be valid for all logged files)? It would be nice for command line users!

Alternatively I could also imagine the extension of the blame functionality in the direction to see a whole history instead of only the last modification. 

Best regards,
Peter Dolland

-----------------------
Von: Johannes Schindelin [mailto:notifications@github.com] 
Gesendet: Dienstag, 2. Oktober 2018 01:06
An: git-for-windows/git
Cc: Dolland Peter MTPCE; Mention
Betreff: Re: [git-for-windows/git] log -L/<regex>/,+1 not accepted (#1856)

It would be appropriate, but what @PhilipOakley asked you, @pdolland, was whether this is Windows-specific behavior. Because if it is not, then the feature request would be better sent to git@vger.kernel.org (the real Git mailing list; please make sure to send plain-text-only mails).
You saw fit to simply delete the issue reporting template instead of filling it out, so I have no way to assess whether WSL would be an option for you.

-----------
Von: Peter Dolland [mailto:notifications@github.com] 
Gesendet: Montag, 1. Oktober 2018 13:26
An: git-for-windows/git
Cc: Dolland Peter MTPCE; Your activity
Betreff: Re: [git-for-windows/git] log -L/<regex>/,+1 not accepted (#1856)

I have no possibility to check this on Linux. 

However, I found out, that the documentation of the –L option is different for blame and log. The documented log –L is working, even if the output is not exactly, what I wanted. Nevertheless, I think it would be appropriate, to admit the syntax of blame for log too. 

Best regards, 

Peter Dolland 

Von: Philip Oakley [mailto:notifications@github.com] 
Gesendet: Montag, 1. Oktober 2018 13:04 
An: git-for-windows/git 
Cc: Dolland Peter MTPCE; Author 
Betreff: Re: [git-for-windows/git] log -L/<regex>/,+1 not accepted (#1856) 


Have you been able to check if this issue is also present on Linux? It may be a a global Git problem rather than just a G-f-W issue. 

I know there were some fairly recent upstream patches regarding the start,end aspects of the the '-L' option (IIRC mainly about the values spanning the end of the file). 

There are a number of these options that do not carry fully between commands. 

— 
You are receiving this because you authored the thread. 
Reply to this email directly, view it on GitHub<https://github.com/git-for-windows/git/issues/1856#issuecomment-425868832>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADShEBzWN4hO6uC4frkbHUWfjC0iOccyks5ugfa0gaJpZM4XBvep>. 

--------- <the original> ------------
Von: Peter Dolland [mailto:notifications@github.com] 
Gesendet: Montag, 1. Oktober 2018 12:01
An: git-for-windows/git
Cc: Dolland Peter MTPCE; Your activity
Betreff: [git-for-windows/git] log -L/<regex>/,+1 not accepted (#1856)

$ git log -L'/DRIVER_STATE = "/',+1 -- plm-dev/Wolke_M600_UTF8.java
fatal: -L argument not 'start,end:file' or ':funcname:file': /DRIVER_STATE = "/,+1
whereas blame with the same arguments does it:
$ git blame -L'/DRIVER_STATE = "/',+1 -- plm-dev/Wolke_M600_UTF8.java
51afb3c491 (Peter 2018-04-19 10:23:41 +0200 51) protected static final String DRIVER_STATE = "180419";
The same behavior with git versions 2.5.1 and 2.19.0.windows.1.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Re: WG: [git-for-windows/git] log -L/<regex>/,+1 not accepted (#1856)

[Jeff King]

On Tue, Oct 02, 2018 at 06:56:29AM +0000, Peter.Dolland@mt.com wrote:

> Please see my original observation below.
> Is it possible, to extend the git-log syntax in the way, that it
> accepts the short -L option (without :file) of blame in unique cases
> (only one file is logged or respectively the -L expression may be
> valid for all logged files)? It would be nice for command line users!

That would be nice, but I suspect in many cases the regex will be less
unique than you might hope. E.g., if you're looking for the log of a
particular function, you care about where it's defined. But unless you
write your regex very carefully, you're going to also match places where
it's called.

I have a hacky script (included below) that uses an already-built ctags
index to pick the correct file.

> Alternatively I could also imagine the extension of the blame
> functionality in the direction to see a whole history instead of only
> the last modification.

Have you tried using a blame interface that supports parent-reblaming
(i.e., once you blame a line to a particular commit, you can restart the
blame from that commit's parent, digging further into history each
time)? I use "tig blame" for this, and I find that I very rarely
actually turn to "log -L".

-Peff

-- >8 --
#!/usr/bin/env perl

if (!@ARGV) {
  print STDERR "usage: git flog [options] <function>\n";
  exit 1;
}

my $func = pop @ARGV;
my $file = get_file_from_tags($func);
my $regex = '[^A-Za-z_]' . $func . '[^A-Za-z0-9_]';
exec qw(git log), "-L:$regex:$file", @ARGV;
exit 1;

sub get_file_from_tags {
  my $token = shift;

  open(my $fh, '<', 'tags')
    or die "unable to open tags: $!\n";
  while (<$fh>) {
    chomp;

    # this isn't exactly right, as the Ex command may contain
    # embedded tabs, but it's accurate for the token and filename,
    # which come before, and probably good enough to match extension fields
    # which come after
    my @fields = split /\t/;

    next unless $fields[0] eq $token;

    # only look for functions; assumes your ctags uses the "kind"
    # extension field. Note also that some implementations write the "kind:"
    # header and some do not. This handles both.
    next unless grep { /^(kind:\s*)?f$/ } @fields;

    # there may be more, but we don't have any way of disambiguating,
    # so just return the first match
    return $fields[1];
  }

  die "unknown token: $token\n";
}