Re: That improved git-gui blame viewer..

["Marco Costalba" <mcostalba@gmail.com>]

On 6/12/07, Junio C Hamano <gitster@pobox.com> wrote:
>
> > Annotate algorithm of qgit is little different in that it starts from
> > the oldest revision that modified a file and goes to the latest. In
> > this way we can have the whole file history annotated in one pass and
> > very fast.
>
> I am not sure about two things in this description.
>
>  (1) Are you emulating CVS-like "a file has an identity, and we
>      follow its changes" model?  How does it handle file split,
>      merge, and code movement in general?
>

It uses 'git rev-list HEAD -- <path>' to get the list of revisions
that modified a path,
I really would like to keep it like that because it is the way 'git'
works, and I would feel uncomfortable in filtering out git results, it
seems quite fragile to me.

This means that file splits, merges, renames etc.. are handled as much
as they are handled in git. IOW *if* 'git rev-list HEAD -- <path>'
returns a list of revisions taking in account all of the above, so it
will, automatically, do qgit.

BTW _currentlly_ git-rev-list does not do that.


>  (2) It is unclear why going from old to new has the advantage
>      of being "one pass", implication of which is that the
>      opposite direction needs to be done as more than one pass.
>      Care to enlighten?
>

Going from oldest to newest has this advantage:

1 - start from a known good first (empty) annotation, i.e. the first
revision in history has an empty annotation (this is a choice to get
consistent results when dealing with git repository started after the
begining of the project, Linux tree started from 2.6.12 is an
example).

2 - Given a good annotation (ann1) at a given time in history you can
calculate the next annotation (ann2), the annotation corresponding to
the next (newer) revision in history that modified the file using just
the diff between the two. If you don't discards ann1 you end up having
both ann1 and ann2.

3 - So at the end of applying all the diff chain you get all the
annotations for all the file revisions, each annotation requires only
the previous one and the corresponding diff.

4 - You don't need to touch anymore an already calculated file, nor
applying the corresponding diff more then one time.

So the complexity of annotating *all* the files revisions grows only
linearly with the revision list size.

 Marco