Bo Yang wrote:
> On Mon, May 10, 2010 at 2:20 AM, Junio C Hamano <gitster@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html