Hi,

[reordering quoted text for convenience]

Bo Yang wrote:

quoted text
> 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.

quoted text
> 2. The diff looks like:
[...]
quoted text
> 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.

quoted text
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html