Re: Multiple line ranges and files in line level history browser

[Thomas Rast <trast@student.ethz.ch>]

Bo Yang wrote:
> On Mon, May 10, 2010 at 2:20 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > I'd rather not to see this in revision.c at all.  The revision.c parser
> > has always been options and then pathspecs and never takes individual
> > filnames, except for "--follow" that is an afterthought checkbox hack that
> > lets the main parser parse and then reject a generic pathspec after the
> > fact.
> 
> Ok, this will be put in the builtin/log.c
[...]
> 1. The definition of TREESAME. TREESAME will be changed to consider
> the line ranges if -L option is given;
> With this, the history simplification can be done very well for line
> level history traversal. And even well for parent rewriting to support
> --graph option.

Doesn't this actually mean it should go in revision.c, after all?

AFAICS you make a case that this feature is an extension of the path
filtering and also of --follow.  This is not strictly speaking true,
since '-- path' only cares about the path itself, '--follow -- path'
tracks only "sufficiently close" renames and '-L0,inf path'[0] tracks
the lines across files even if it's only small chunks.

But I still think it's a good argument.  And then if git-log learns
about it, why should this be a special case that only the log family
understands, but not rev-list?

And since we can't remove --follow for hysterical raisins, you might
as well link the whole "what moved where" tracking logic to a place
where it helps fixing --follow.

Or am I totally on the wrong page?


[0] making up syntax for the purposes of the example, please don't
    think of this as normative or even a good idea

-- 
Thomas Rast
trast@{inf,student}.ethz.ch