On 3/11/06, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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, m - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html