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

From: Thomas Rast <trast@student.ethz.ch>
Date: May 12, 2010, 07:57 UTC
Message-ID: <201005120957.10961.trast@student.ethz.ch>
In-Reply-To: <AANLkTimCT7euE0CjGBx88MlfVJhxVo1GdOtnMhtZqBQs@mail.gmail.com>

Bo Yang wrote:

Show 8 quoted lines

> 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

[...]

Show 5 quoted lines

> 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