Re: [PATCH v9 3/5] Implement line-history search (git log -L)

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

Junio C Hamano <gitster@pobox.com> writes:

> Thomas Rast <trast@student.ethz.ch> 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