Re: [PATCH] git-cvsimport-script: parse multidigit revisions

Linus Torvalds wrote: On Mon, 25 Jul 2005, Linus Torvalds wrote: And they are in the wrong order, so "cvsimport" ends up committing the last one, which is the _empty_ one. Notice? We'll end up committing "COPYING 1.1" (the empty initial create) even though we _should_ have committed "COPYING

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

Petr Baudis wrote: Dear diary, on Wed, Apr 20, 2005 at 10:32:35PM CEST, I got a letter where Ingo Molnar <[EMAIL PROTECTED]> told me that... * Petr Baudis <[EMAIL PROTECTED]> wrote: yet another thing: what is the canonical 'pasky way' of simply nuking the current files and checking out the latest

Re: full kernel history, in patchset format

Catalin Marinas wrote: Ingo Molnar <[EMAIL PROTECTED]> wrote: i've converted the Linux kernel CVS tree into 'flat patchset' format, which gave a series of 28237 separate patches. (Each patch represents a changeset, in the order they were applied. I've used the cvsps utility.) AFAIK, cvsps uses t

Re: full kernel history, in patchset format

Ingo Molnar wrote: * Ingo Molnar <[EMAIL PROTECTED]> wrote: the patches contain all the existing metadata, dates, log messages and revision history. (What i think is missing is the BK tree merge information, but i'm not sure we want/need to convert them to GIT.) author names are abbreviated, e.

Re: Handling renames.

Linus Torvalds wrote: On Thu, 14 Apr 2005, Ingo Molnar wrote: there's no redundancy caused by this method: only renames (which are rare) go through the rename_commit redirection. (to speed up the lookup the rename_commit object could cache the offset of the two names within their tree objects.)