threads / discuss / 9676

git-import.sh using git-fast-import

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

## tl;dr

3 messages between Aug 27, 2007 and Aug 29, 2007.

replies: 2people: 3as markdown or json

Nguyen Thai Ngoc Duy· Aug 27, 2007, 16:13 UTC · lore

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· Aug 27, 2007, 17:44 UTC · re: Nguyen Thai Ngoc Duy · lore

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

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:

Show 8 quoted lines

> 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· Aug 29, 2007, 15:20 UTC · lore

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

On Wed, 29 Aug 2007, Jeff King wrote:

Show 10 quoted lines

> 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