Re: What's in git.git

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Mar 10, 2006, 11:59 UTC
Message-ID: <46a038f90603100359o402d9e32j268e1b746d0bdfc8@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.63.0603101215100.25810@wbgn013.biozentrum.uni-wuerzburg.de>

On 3/11/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> The history is linearized, and the commits are ordered accordingly, then
> to be passed to git-annotate/-blame.

Exactly.

If a process has already done the costly git-rev-list for other purposes (say, grab logentries of the relevant commits), and wants to also run annotate/blame, it should be able to reuse it cheaply, by passing -S filename. Possibly an IDE (or gitk/qgit) would want to do this.

Now, what I use it for in git-cvsserver is to "flatten" merges. CVS clients don't really understand that we know about parallel history, so every time we have a merge the view that the CVS client gets is of a "merge commit" with a merge summary. And I sweep the merged commits under the carpet.

(there's some arbitrary nondeterministic magic in how I pick what side to track and what side to merge. let's not think about that too much. but I just want git-blame to see a somewhat simplified git-rev-list).

does that help?

cheers,