git-import.sh using git-fast-import

git-import.sh using git-fast-import

[Nguyen Thai Ngoc Duy]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

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

[-- Attachment #2: git-import.sh --]
[-- Type: application/x-sh, Size: 538 bytes --]

Re: git-import.sh using git-fast-import

[Johannes Gilger]

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'

Re: git-import.sh using git-fast-import

[Nicolas Pitre]

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