Re: GSoC draft proposal: Line-level history browser

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 23, 2010, 18:57 UTC
Message-ID: <20100323185745.GA1382@progeny.tock>
In-Reply-To: <41f08ee11003222301y569a5972q3c67d10c77abe27a@mail.gmail.com>

Hi,

[reordering quoted text for convenience]

Bo Yang wrote:

> I can't understand fully about your above strategy. I think we can
> category the code change into two cases:

Thanks! What you said is much more coherent than the vague things I wrote.

> 2. The diff looks like:

[...]

Show 5 quoted lines

> This means, the code here is added from scratch. Here, I think we have
> three options.
> 1. Find if the new code is moved here from other place.
> 2. Find if the new code is copied from other place.
> 3. We find the end of the history, so stop here.

If the code is copied verbatim from elsewhere, this is something ‘git blame’ is already very good at. See [1].

Fuzzy matching is a big pain. ‘git blame’ knows how to ignore whitespace. Dscho suggested counting common words. Maybe there are some other ways. I think there is a real danger of getting lost in this problem and wasting a lot of time, so although it is very interesting, I would consider any progress in this area a bonus rather than a goal.

Show 19 quoted lines

> 1. The diff looks like:
> 
> @@ -1008,29 +1000,29 @@ int cmd_format_patch(int argc, const char
> **argv, const char *prefix)
>                 add_signoff = xmemdupz(committer, endpos - committer + 1);
>         }
> 
> -       for (i = 0; i < extra_hdr_nr; i++) {
> -               strbuf_addstr(&buf, extra_hdr[i]);
> +       for (i = 0; i < extra_hdr.nr; i++) {
> +               strbuf_addstr(&buf, extra_hdr.items[i].string);
>                 strbuf_addch(&buf, '\n');
>         }
> 
> 
> ie: there is both deletion and addition in a change. And this means we
> modify some lines of the code. So, what we do will be tracing the two
> 'minus' lines and then find another diff. Start trace from that diff
> recursively.

If you can make a heuristic along these lines this work well, I think it would be great. I imagine it might work very well for commits that made nice, small changes (like many of those in git.git). Jakub pointed out some of the difficulties, and I like to hope your idea of “when in doubt, include more lines” may work well in many cases in git.git still.

Good luck, and thank you for taking my crazy ideas seriously. :)

Regards, Jonathan

[1] See v1.4.4-rc1~2 (Merge branch 'jc/pickaxe', 2006-11-07) and the commits preceding it. About that series, Junio wrote:

	Actually the plan is to make it do _true_ pickaxe,
	although it will most likely end up either in dustbin or
	replace blame.

It replaced blame.

I am not actually sure, but I assume “true pickaxe” refers to the goals described in <http://gitster.livejournal.com/35628.html> and the linked-to message.