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 - To unsubscribe from this list: 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
