Hi,
Arch Linux's git 2.12.2-4's git-log(1) says
-L <start>,<end>:<file>, -L :<funcname>:<file>
Trace the evolution of the line range given by "<start>,<end>"
(or the function name regex <funcname>) within the <file>. You
may not give any pathspec limiters. This is currently limited
to a walk starting from a single revision, i.e. you may only
give zero or one positive revision arguments. You can specify
this option more than once.
<start> and <end> can take one of these forms:
number
If <start> or <end> is a number, it specifies an absolute
line number (lines count from 1).
It doesn't say one or both of start and end may be omitted. Thus `-L
,:foobar.c' is valid with start defaulting to 1 and end to the number of
lines in foobar.c.
Nor does it explain if 1,42 covering all of foobar.c as it is now swells
to be 1,314 as the commits are walked to larger versions of foobar.c.
This was noticed because I've started with foo.c and bar.c, and each was
`git mv'd to foobar.c in separate commits that were then each merged.
I'm trying to `git log' HEAD's foobar.c and have it walk past the merges
to show be foo.c and bar.c's history.
`git log HEAD -- foobar.c foo.c bar.c' works, but one has to specify all
the old names. `git log -L ,:foobar.c' works for a simple test case,
but I don't know if changes outside of foobar.c's current 1,42 lines
would always show up. And also -L triggers patches and --no-patch
doesn't stop that; bug? The -L logic seems particular to `git log' so
I can't have git-rev-list(1) do that work to provide the commits and
then log them separately.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
