{"thread":{"id":"49464","subject":"WG: [git-for-windows/git] log -L//,+1 not accepted (#1856)","startedAt":"2018-10-02T07:06:21Z","lastAt":"2018-10-02T14:43:46Z","messageCount":2,"participants":["peter.dolland@mt.com","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"359407","messageId":"C19A54411B361046A786B5FA02D5689FE3B01FF9@ch00sem22.mt.mtnet","threadId":"49464","inReplyTo":"git-for-windows/git/issues/1856/426092877@github.com","subject":"WG: [git-for-windows/git] log -L//,+1 not accepted (#1856)","fromName":"","fromEmail":"peter.dolland@mt.com","sentAt":"2018-10-02T06:56:29Z","receivedAt":"2018-10-02T07:06:21Z","isPatch":false,"sender":{"key":"peter.dolland@mt.com","avatar":null},"body":"Please see my original observation below.\nIs 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!\n\nAlternatively I could also imagine the extension of the blame functionality in the direction to see a whole history instead of only the last modification. \n\nBest regards,\nPeter Dolland\n\n-----------------------\nVon: Johannes Schindelin [mailto:notifications@github.com] \nGesendet: Dienstag, 2. Oktober 2018 01:06\nAn: git-for-windows/git\nCc: Dolland Peter MTPCE; Mention\nBetreff: Re: [git-for-windows/git] log -L//,+1 not accepted (#1856)\n\nIt 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).\nYou 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.\n\n-----------\nVon: Peter Dolland [mailto:notifications@github.com] \nGesendet: Montag, 1. Oktober 2018 13:26\nAn: git-for-windows/git\nCc: Dolland Peter MTPCE; Your activity\nBetreff: Re: [git-for-windows/git] log -L//,+1 not accepted (#1856)\n\nI have no possibility to check this on Linux. \n\nHowever, 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. \n\nBest regards, \n\nPeter Dolland \n\nVon: Philip Oakley [mailto:notifications@github.com] \nGesendet: Montag, 1. Oktober 2018 13:04 \nAn: git-for-windows/git \nCc: Dolland Peter MTPCE; Author \nBetreff: Re: [git-for-windows/git] log -L//,+1 not accepted (#1856) \n\n\nHave 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. \n\nI 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). \n\nThere are a number of these options that do not carry fully between commands. \n\n— \nYou are receiving this because you authored the thread. \nReply to this email directly, view it on GitHub, or mute the thread. \n\n--------- ------------\nVon: Peter Dolland [mailto:notifications@github.com] \nGesendet: Montag, 1. Oktober 2018 12:01\nAn: git-for-windows/git\nCc: Dolland Peter MTPCE; Your activity\nBetreff: [git-for-windows/git] log -L//,+1 not accepted (#1856)\n\n$ git log -L'/DRIVER_STATE = \"/',+1 -- plm-dev/Wolke_M600_UTF8.java\nfatal: -L argument not 'start,end:file' or ':funcname:file': /DRIVER_STATE = \"/,+1\nwhereas blame with the same arguments does it:\n$ git blame -L'/DRIVER_STATE = \"/',+1 -- plm-dev/Wolke_M600_UTF8.java\n51afb3c491 (Peter 2018-04-19 10:23:41 +0200 51) protected static final String DRIVER_STATE = \"180419\";\nThe same behavior with git versions 2.5.1 and 2.19.0.windows.1.\n—\nYou are receiving this because you are subscribed to this thread.\nReply to this email directly, view it on GitHub, or mute the thread.\n"},{"id":"359420","messageId":"20181002144342.GB24480@sigill.intra.peff.net","threadId":"49464","inReplyTo":"C19A54411B361046A786B5FA02D5689FE3B01FF9@ch00sem22.mt.mtnet","subject":"Re: WG: [git-for-windows/git] log -L//,+1 not accepted (#1856)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-02T14:43:42Z","receivedAt":"2018-10-02T14:43:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 02, 2018 at 06:56:29AM +0000, Peter.Dolland@mt.com wrote:\n\n> Please see my original observation below.\n> Is it possible, to extend the git-log syntax in the way, that it\n> accepts the short -L option (without :file) of blame in unique cases\n> (only one file is logged or respectively the -L expression may be\n> valid for all logged files)? It would be nice for command line users!\n\nThat would be nice, but I suspect in many cases the regex will be less\nunique than you might hope. E.g., if you're looking for the log of a\nparticular function, you care about where it's defined. But unless you\nwrite your regex very carefully, you're going to also match places where\nit's called.\n\nI have a hacky script (included below) that uses an already-built ctags\nindex to pick the correct file.\n\n> Alternatively I could also imagine the extension of the blame\n> functionality in the direction to see a whole history instead of only\n> the last modification.\n\nHave you tried using a blame interface that supports parent-reblaming\n(i.e., once you blame a line to a particular commit, you can restart the\nblame from that commit's parent, digging further into history each\ntime)? I use \"tig blame\" for this, and I find that I very rarely\nactually turn to \"log -L\".\n\n-Peff\n\n-- >8 --\n#!/usr/bin/env perl\n\nif (!@ARGV) {\n print STDERR \"usage: git flog [options] \\n\";\n exit 1;\n}\n\nmy $func = pop @ARGV;\nmy $file = get_file_from_tags($func);\nmy $regex = '[^A-Za-z_]' . $func . '[^A-Za-z0-9_]';\nexec qw(git log), \"-L:$regex:$file\", @ARGV;\nexit 1;\n\nsub get_file_from_tags {\n my $token = shift;\n\n open(my $fh, '<', 'tags')\n or die \"unable to open tags: $!\\n\";\n while (<$fh>) {\n chomp;\n\n # this isn't exactly right, as the Ex command may contain\n # embedded tabs, but it's accurate for the token and filename,\n # which come before, and probably good enough to match extension fields\n # which come after\n my @fields = split /\\t/;\n\n next unless $fields[0] eq $token;\n\n # only look for functions; assumes your ctags uses the \"kind\"\n # extension field. Note also that some implementations write the \"kind:\"\n # header and some do not. This handles both.\n next unless grep { /^(kind:\\s*)?f$/ } @fields;\n\n # there may be more, but we don't have any way of disambiguating,\n # so just return the first match\n return $fields[1];\n }\n\n die \"unknown token: $token\\n\";\n}\n"}]}