threads / discuss / 55754

Re: Formatting options are ignored when tracking functions

Subject: Re: Formatting options are ignored when tracking functions

## tl;dr

5 messages between May 22, 2021 and May 23, 2021.

replies: 4people: 4as markdown or json

Philippe Blain· May 22, 2021, 01:58 UTC · lore
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· May 22, 2021, 03:55 UTC · re: Philippe Blain · lore
Hi Philippe,
On 22/05/21 08.58, Philippe Blain wrote:
Show 9 quoted lines
> 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:<function>:<file> --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· May 23, 2021, 18:11 UTC · re: Philippe Blain · lore
Philippe Blain <levraiphilippeblain@gmail.com> writes:
Show 5 quoted lines
> 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<text>" can be used to find commits that change the number of occurrences of <text>, 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· May 23, 2021, 18:20 UTC · re: Junio C Hamano · lore
Hi Junio,
Le 2021-05-23 à 14:11, Junio C Hamano a écrit :
Show 26 quoted lines
> Philippe Blain <levraiphilippeblain@gmail.com> 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<text>" can be used to find commits that change the number of
> occurrences of <text>, 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· May 23, 2021, 19:28 UTC · re: Philippe Blain · lore
Philippe Blain wrote:
Show 6 quoted lines
> 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

← back to recent threads