Re: Formatting options are ignored when tracking functions

From: Philippe Blain <levraiphilippeblain@gmail.com>
Date: May 23, 2021, 18:20 UTC
Message-ID: <d801fe76-f40d-91ef-653e-925aba0fbdf4@gmail.com>
In-Reply-To: <xmqqczthnwuu.fsf@gitster.g>

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.