Re: Efficient way to import snapshots?

From: Craig Boston <craig@olyun.gank.org>
Date: Jul 30, 2007, 20:10 UTC
Message-ID: <20070730201023.GC64467@nowhere>
In-Reply-To: <alpine.LFD.0.999.0707301240330.4161@woody.linux-foundation.org>

On Mon, Jul 30, 2007 at 12:52:52PM -0700, Linus Torvalds wrote:

> On Mon, 30 Jul 2007, Craig Boston wrote:
> > 1. Will it notice deleted files?
> 
> Yes, although I think you need to do "git commit -a" for that.

Ah, nice. I had underestimated how smart git is, that was the whole reason I did the 'git rm -r .' dance at first :-)

> > 2. How can I tell it what branch to commit to?
> 
> Whatever branch is checked out in the GIT_DIR will be the one that it 
> commits to.

Hmm, ok. I tried it out and it was unhappy with GIT_DIR pointing at the bare repository (no index file I presume), so I'll need a minimum of one clone. With clone -s the repository itself shouldn't take up hardly any space. It sounds like my options are:

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.

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.

 * Unless of course there's a way to forcibly change the state that the
   repository thinks it's in without physically checking out the files.
   I think it would still need to update index however.

   I tried git reset --soft without success.  If this is possible, it
   also makes option 1 more attractive if I can safely delete the
   working copy files that it won't be using anyway.

Craig