# git-import.sh using git-fast-import 3 messages from 2007-08-27 to 2007-08-29. Participants: Nguyen Thai Ngoc Duy, Johannes Gilger, Nicolas Pitre. Thread: https://gitlist.dev/t/9676 ## Nguyen Thai Ngoc Duy, 2007-08-27 16:13 Subject: git-import.sh using git-fast-import Message-ID: URL: https://gitlist.dev/e/fcaeb9bf0708270913o37b2dbdfw2f5f7d89d9ab1d21%40mail.gmail.com ``` It is not really good. It does not run as fast as git-add && git-commit. But it can swallow big directories that git-add && git-commit can't. So I think I would share. It's also simpler than those in contrib/fast-import, making it a good start for git-fast-import's new users. To run it, move inside the directory you want to import then type ./git-import.sh master 'your import message' -- Duy ``` ## Johannes Gilger, 2007-08-27 17:44 Subject: Re: git-import.sh using git-fast-import Message-ID: <46D30D8C.204@hackvalue.de> URL: https://gitlist.dev/e/46D30D8C.204%40hackvalue.de In-Reply-To: ``` Hi, nice of you to share, but i think the policy on this mailing list is to include patches (and probably shellscripts like your's) in the message itself rather than create a file attachment. I for one find it much more convenient. regards, jojo Nguyen Thai Ngoc Duy wrote: > It is not really good. It does not run as fast as git-add && > git-commit. But it can swallow big directories that git-add && > git-commit can't. So I think I would share. It's also simpler than > those in contrib/fast-import, making it a good start for > git-fast-import's new users. > > To run it, move inside the directory you want to import then type > ./git-import.sh master 'your import message' ``` ## Nicolas Pitre, 2007-08-29 15:20 Subject: Re: git-import.sh using git-fast-import Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.999.0708291116310.16727%40xanadu.home In-Reply-To: <20070829041120.GA25779@coredump.intra.peff.net> ``` On Wed, 29 Aug 2007, Jeff King wrote: > On Tue, Aug 28, 2007 at 11:47:25PM -0400, Shawn O. Pearce wrote: > > > Yea, so like the parallel pack-objects experiment that Nico had > > done recently we decreased wall-clock time at the expense of using a > > larger amount of the system resources. That is bad as we use more > > CPU time than we saved in wallclock time. Usually a bad tradeoff, > > unless you have a realtime requirement you have to meet. > > It depends. If we all have 64-core processors in a few years, then it > might be a better tradeoff. Depends. In the experiment I did, I clearly identified flaws showing that the direction was bad and that another approach has to be pursued. Thinking in terms of 64-core processors is no excuse for bad designs. > Of course, some users might want to optimize > for wall-clock time, while others want power consumption, etc. Better get both at the same time when possible. Nicolas ```