mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Philippe Blain <>
To: Junio C Hamano <>
Cc:,, Thomas Rast <>
Subject: Re: Formatting options are ignored when tracking functions
Date: Sun, 23 May 2021 14:20:58 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <xmqqczthnwuu.fsf@gitster.g>

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<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.



  reply	other threads:[~2021-05-23 18:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-22  1:58 Formatting options are ignored when tracking functions Philippe Blain
2021-05-22  3:55 ` Bagas Sanjaya
2021-05-23 18:11 ` Junio C Hamano
2021-05-23 18:20   ` Philippe Blain [this message]
2021-05-23 19:28     ` Felipe Contreras
  -- strict thread matches above, loose matches on Subject: below --
2021-05-21 21:18 Aidan
2021-05-23  2:28 ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).