# Re: Formatting options are ignored when tracking functions 5 messages from 2021-05-22 to 2021-05-23. Participants: Philippe Blain, Bagas Sanjaya, Junio C Hamano, Felipe Contreras. Thread: https://gitlist.dev/t/55754 ## Philippe Blain, 2021-05-22 01:58 Subject: Re: Formatting options are ignored when tracking functions Message-ID: URL: https://gitlist.dev/e/EE7D39E6-D826-49E2-AD0E-090A83DFDEC1%40gmail.com ``` Hi Aidan, I believe this is working as advertised: only the first line of the commit message is shown. However as mentioned in the doc, the -L option also triggers patch output (-p), which you can omit if you explicitely add --no-patch (or shorter, -s). Cheers, Philippe. ``` ## Bagas Sanjaya, 2021-05-22 03:55 Subject: Re: Formatting options are ignored when tracking functions Message-ID: URL: https://gitlist.dev/e/b3035e1c-79fc-e285-fd0e-fca246ae5190%40gmail.com In-Reply-To: ``` Hi Philippe, On 22/05/21 08.58, Philippe Blain wrote: > Hi Aidan, > > I believe this is working as advertised: only the first line of the commit message is shown. > However as mentioned in the doc, the -L option also triggers patch output (-p), > which you can omit if you explicitely add --no-patch (or shorter, -s). > > Cheers, > Philippe. > So the complete command for --oneline with -L in order to produce similar output as other cases is `git log -L:: --oneline --no-patch`. I wonder if we can make --oneline implies --no-patch when -L is given, right? -- An old man doll... just what I always wanted! - Clara ``` ## Junio C Hamano, 2021-05-23 18:11 Subject: Re: Formatting options are ignored when tracking functions Message-ID: URL: https://gitlist.dev/e/xmqqczthnwuu.fsf%40gitster.g In-Reply-To: ``` Philippe Blain writes: > I believe this is working as advertised: only the first line of > the commit message is shown. > However as mentioned in the doc, the -L option also triggers patch > output (-p), which you can omit if you explicitely add --no-patch > (or shorter, -s). Heh, I think "working as advertised" is not wrong per-se, but this feels like a clear design mistake to me, at least at the UI level. Admittedly, I've never used "log -L" in scripts and I've always used it interactively, in a context that I want to see the patch output, so this did not bother me so far. But what commits -L decides have relevant changes and how these commits are shown ought to be orthogonal. It surely may need to run the content-level diff machinery to see if each commit affects the area of the code specified via the -L option, but just like "git log -S" can be used to find commits that change the number of occurrences of , and allows the users to choose to view them with "-p" (but not force the --patch mode on), it should behave the same way, I would think. With a clear migration plan, we should be able to fix this over time, I would think. ``` ## Philippe Blain, 2021-05-23 18:20 Subject: Re: Formatting options are ignored when tracking functions Message-ID: URL: https://gitlist.dev/e/d801fe76-f40d-91ef-653e-925aba0fbdf4%40gmail.com In-Reply-To: ``` Hi Junio, Le 2021-05-23 à 14:11, Junio C Hamano a écrit : > Philippe Blain writes: > >> I believe this is working as advertised: only the first line of >> the commit message is shown. >> However as mentioned in the doc, the -L option also triggers patch >> output (-p), which you can omit if you explicitely add --no-patch >> (or shorter, -s). > > Heh, I think "working as advertised" is not wrong per-se, but this > feels like a clear design mistake to me, at least at the UI level. > Admittedly, I've never used "log -L" in scripts and I've always used > it interactively, in a context that I want to see the patch output, > so this did not bother me so far. > > But what commits -L decides have relevant changes and how these > commits are shown ought to be orthogonal. It surely may need to run > the content-level diff machinery to see if each commit affects the > area of the code specified via the -L option, but just like "git log > -S" can be used to find commits that change the number of > occurrences of , and allows the users to choose to view them > with "-p" (but not force the --patch mode on), it should behave the > same way, I would think. > > With a clear migration plan, we should be able to fix this over > time, I would think. > I agree with that. I was just pointing out that it does work as the doc says it should work, without implying anything about what should be the behaviour in an ideal world. In fact in an ideal world, '-L' would support all "kinds" of diff output, i.e. --stat, --summary, etc. I do not have a clear opinion on a migration path; if consensus can be reached that not implying '--patch' is a better behaviour, then changing the behaviour would be OK. If some people use scripts that parse 'git log -L' ouptut expecting that '-p' is implied, I would expect it's pretty easy to notice the breakage and add the now-required switch... but I'll let others be the judge of that. Cheers, Philippe. ``` ## Felipe Contreras, 2021-05-23 19:28 Subject: Re: Formatting options are ignored when tracking functions Message-ID: <60aaacdb6a7da_53920893@natae.notmuch> URL: https://gitlist.dev/e/60aaacdb6a7da_53920893%40natae.notmuch In-Reply-To: ``` Philippe Blain wrote: > Le 2021-05-23 à 14:11, Junio C Hamano a écrit : > I do not have a clear opinion on a migration path; if consensus can be reached > that not implying '--patch' is a better behaviour, then changing the behaviour > would be OK. If some people use scripts that parse 'git log -L' ouptut expecting > that '-p' is implied, I would expect it's pretty easy to notice the breakage and > add the now-required switch... but I'll let others be the judge of that. I agree; it should be easy to notice the breakage. I don't think any migration path would help, we should just switch. But the git project has a tendency to worry about hypothetical users. This is the only thing I can imagine doing for those users: --- a/builtin/log.c +++ b/builtin/log.c @@ -262,8 +262,13 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix, load_ref_decorations(&decoration_filter, decoration_style); } - if (rev->line_level_traverse) + if (rev->line_level_traverse) { + if (!(rev->diffopt.output_format & DIFF_FORMAT_NO_OUTPUT) && !rev->diff) { + advise("In the future you will need to specify --patch. Hit Enter to proceed."); + getc(stdin); + } line_log_init(rev, line_cb.prefix, &line_cb.args); + } setup_pager(); } -- Felipe Contreras ```