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

Junio C Hamano [off-list ref] writes:

Thomas Rast [off-list ref] writes:

quoted

+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