Re: [RFC] faking cvs annotate

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Dec 16, 2005, 04:37 UTC
Message-ID: <46a038f90512152037u66993aadg566a2a47abd279c9@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.63.0512160229140.6323@wbgn013.biozentrum.uni-wuerzburg.de>

On 12/16/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> For starters, you could use my attempt:
> http://www.gelato.unsw.edu.au/archives/git/0508/7171.html

Not bad at all! I might simplify it a bit (won't need the commitmsg parsing), and see if how fast I can make it.

> It does not fool any CVS user,

Ah, no. Those have been fooled already ;-)

> However, I learnt to use git-whatchanged in the meantime, and I'll
> probably never go back.

Of course. I'm trying to meet a few the expectations of popular cvs clients (cli, TortoiseCVS, Eclipse, etc). If a workable git-annotate falls out of this, oh well.

OTOH, yours didn't get included. Any particular reasons? (other than stressing the point that you should use whatchanged/pickaxe?)

Also! On 12/16/05, Junio C Hamano <junkio@cox.net> wrote:

Show 5 quoted lines

> I haven't actively done anything but one of the good things that
> could happen is to split out the access routines for annotate
> database qgit build when run the first time in the repository,
> and make them available to other Porcelains.  There is no need
> to reinvent the wheel.

That would be cool! Though my particular implementation may be a tad unconventional in its view of the "file history" as a strictly linear thing. Normal git porcelains don't even blink when dealing with branching/merging development histories.

cheers,

martin