Re: That improved git-gui blame viewer..

From: Marco Costalba <mcostalba@gmail.com>
Date: Jun 12, 2007, 11:27 UTC
Message-ID: <e5bfff550706120427g7ad9d38bpc34d9ea284ace693@mail.gmail.com>
In-Reply-To: <7vbqflll55.fsf@assigned-by-dhcp.pobox.com>

On 6/12/07, Junio C Hamano <gitster@pobox.com> wrote:

Show 12 quoted lines

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

Show 5 quoted lines

>  (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