# WG: [git-for-windows/git] log -L//,+1 not accepted (#1856) 2 messages from 2018-10-02 to 2018-10-02. Participants: peter.dolland@mt.com, Jeff King. Thread: https://gitlist.dev/t/49464 ## peter.dolland@mt.com, 2018-10-02 06:56 Subject: WG: [git-for-windows/git] log -L//,+1 not accepted (#1856) Message-ID: URL: https://gitlist.dev/e/C19A54411B361046A786B5FA02D5689FE3B01FF9%40ch00sem22.mt.mtnet In-Reply-To: ``` 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//,+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//,+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//,+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, or mute the thread. --------- ------------ 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//,+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. ``` ## Jeff King, 2018-10-02 14:43 Subject: Re: WG: [git-for-windows/git] log -L//,+1 not accepted (#1856) Message-ID: <20181002144342.GB24480@sigill.intra.peff.net> URL: https://gitlist.dev/e/20181002144342.GB24480%40sigill.intra.peff.net In-Reply-To: ``` 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] \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"; } ```