threads / discuss / 45933

git-log(1) Doesn't Describe -L start,end Fully.

Subject: git-log(1) Doesn't Describe -L start,end Fully.

## tl;dr

One message between May 11, 2017 and May 11, 2017.

replies: 0people: 1as markdown or json

Ralph Corderoy· May 11, 2017, 13:45 UTC · lore
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

← back to recent threads