From: Craig Boston <craig@olyun.gank.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Efficient way to import snapshots?
Date: Mon, 30 Jul 2007 15:10:23 -0500 [thread overview]
Message-ID: <20070730201023.GC64467@nowhere> (raw)
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
next prev parent reply other threads:[~2007-07-30 20:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-30 18:07 Efficient way to import snapshots? Craig Boston
2007-07-30 18:56 ` Linus Torvalds
2007-07-30 19:29 ` Craig Boston
2007-07-30 19:52 ` Linus Torvalds
2007-07-30 20:10 ` Craig Boston [this message]
2007-07-30 21:29 ` Junio C Hamano
2007-07-30 21:49 ` Craig Boston
2007-07-30 21:04 ` Junio C Hamano
2007-07-30 23:19 ` Linus Torvalds
2007-07-30 21:55 ` Junio C Hamano
2007-07-30 23:27 ` Linus Torvalds
2007-07-30 23:59 ` Junio C Hamano
2007-07-31 0:45 ` Linus Torvalds
2007-07-31 0:47 ` Junio C Hamano
2007-07-30 22:20 ` Craig Boston
2007-07-30 23:30 ` Linus Torvalds
2007-07-31 1:17 ` Craig Boston
2007-07-31 1:44 ` Linus Torvalds
2007-07-31 4:23 ` Theodore Tso
2007-07-31 13:53 ` Craig Boston
2007-07-31 15:50 ` Linus Torvalds
2007-07-31 16:15 ` Theodore Tso
2007-07-31 6:23 ` David Kastrup
2007-07-31 7:54 ` Florian Weimer
2007-07-31 8:48 ` David Kastrup
2007-07-30 21:22 ` Jakub Narebski
2007-07-30 21:54 ` David Kastrup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070730201023.GC64467@nowhere \
--to=craig@olyun.gank.org \
--cc=git@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).