Re: Efficient way to import snapshots?

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 30, 2007, 21:29 UTC
Message-ID: <7vabtdk2ch.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070730201023.GC64467@nowhere>

Craig Boston <craig@olyun.gank.org> writes:

Show 10 quoted lines

> 1) Have a separate repository clone for each branch that I want to
> import to and leave that branch permanently checked out.  I lose the
> disk space for N working copies, but on the server I'm doing the import
> on, it's not a huge issue, especially with ZFS compression ;-)
>
>  * This might not actually be so bad if I put the .git directory inside
>    of the CVS checkout directory and used it as my "working copy".  I
>    just need to insure that git doesn't create any additional files in
>    there, as cvsup is really picky about not deleting files that it
>    didn't create, even if they were removed from CVS.

With one of the projects hosted on CVS I have to interoperate with, that is what I do. For historical reasons I do not use git-cvsimport/exportcommit for this one, but basically:

 - "cvs co" to prime the working tree;
 - "echo CVS >.gitignore";
 - "git init && git add . && git commit";
 - "git checkout -b mine";

then I work in "mine" branch. When other people have something to say, I do:

 - "git checkout master";
 - "cvs up";
 - "git add <whatever was added with the above cvs up>";
 - "git commit -a";
 - "git rebase master mine";

When feeding my own changes back to CVS, I would:

 - "git checkout master";
 - "cvs up" to make sure other people do not have any stuff;
 - "git show-branch master mine" to see what I have;

 - "git cherry-pick <whatever the change I want to feed back>";
 - "cvs commit";
 - repeat the last two steps for all the changes I want;

 - "git rebase master mine";

I only need to make sure not to commit on "master", and not to run "cvs up" while on "mine".

This can be extended to more than one CVS branches by using different branches than "master".

> 2) Have one repository clone that gets re-used for each import, with the
>    "checked out" branch getting changed before the import.  As far as I can
>    tell this means suffering the "git checkout" overhead for 30,000 files,
>    which is conceptually inefficient but in real time only a minute or so.

That should only be "conceptually" in fact, as switching between branches should not touch paths that are the same between branches.