Re: Progress report on git-blame

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Sun, 26 Jan 2014 14:05:17 -0500
> 
> > Perhaps we should define what it means "find the history of that chunk
> > of text".  I'm not sure we all talk about the same use case.
> 
> Find the sequence of patches (with their corresponding log comments)
> that results in that chunk of text (presented in reverse-chronological
> order).

How do you define "that chunk of text"?  For the initial (latest)
revision, the answer is clear.  But, as you go backwards in time, the
text becomes less and less similar to what it is today, and can also
move around.  So which revisions are relevant to "that chunk of text"
becomes harder and harder to decide.  What is today 10 lines could
once be only one, and could have been moved from some other place, or
constructed from several different parts, each one taken from a
different place.  Or something that is a function today might have
been just a code fragment in the past, part of some other function.

When we the humans look at the results of applying changes in reverse,
we can make that decision because we know what we are looking for:
some specific trait of the original code in which we are interested.
But how can a program know that?  How can you explain it what you are
interested in?

The usual pattern I apply 'annotate' goes like this:

  a) annotate foo.c, find the revision that changed "that chunk of
     text"

  b) examine the relevant parts of the diffs for that revision

  c) if the diffs don't show what I'm looking for, annotate foo.c as
     it was before that revision, and go back to b)

The crucial parts here are (1) to examine the diffs, and (2) decide
where are "the relevant parts" to look.  How can we do this
programmatically, so that the "history of that chunk of text" will
indeed show what we want it to?