Hi Junio,
Le 2021-05-23 à 14:11, Junio C Hamano a écrit :
Philippe Blain <levraiphilippeblain@xxxxxxxxx> 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.
