Junio C Hamano <gitster@xxxxxxxxx> writes:
> Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
>
>> +void line_log_init(struct rev_info *rev, const char *prefix, struct
>> string_list *args)
>> +{
>> + struct commit *commit = NULL;
>> + struct line_log_data *range;
>> +
>> + commit = check_single_commit(rev);
>> + range = parse_lines(commit, prefix, args);
>> + add_line_range(rev, commit, range);
>> +
>> + if (!rev->diffopt.detect_rename) {
>> + int i, count = 0;
>> + struct line_log_data *r = range;
>> + const char **paths;
>> + while (r) {
>> + count++;
>> + r = r->next;
>> + }
>> + paths = xmalloc((count+1)*sizeof(char *));
>> + r = range;
>> + for (i = 0; i < count; i++) {
>> + paths[i] = xstrdup(r->spec->path);
>> + r = r->next;
>> + }
>> + paths[count] = NULL;
>> + init_pathspec(&rev->diffopt.pathspec, paths);
>> + free(paths);
>> + }
>> +}
>
> Why not do the pathspec limitation under "-M"?
>
> It is not like you are picking up origins of blocks of lines copied
> or moved from other files like "blame -C" does, so I suspect it
> would be simpler to mimic what --follow does, which is to (1) use
> the pathspec to follow the paths you care about, and then (2) when
> you find one or more of the paths you were following disappear in a
> commit, only at that point you re-check to see if there are other
> paths that existed in the parent that the disappeared paths were
> renamed from, and match with that one.
It's acting too soon though. The way log -L is currently wired, we do
one revision walk with the pathspec filter already enabled to do the
topo sorting. Wiring it in *at that point* would be equivalent to
fixing --follow.
Which I plan to do Real Soon Now(tm). But let's not open too many cans
of worms at the same time.
--
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