Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'

["Han-Wen Nienhuys" <hanwenn@gmail.com>]

2007/11/22, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > The cool thing about git-fast-import is that it reads from stdin, has a
> > very easy to use programmatic interface, and does not impose any order
> > on how you enter the information.
> >
> > This doesn't seem to be mirrored by this script?
>
> Umm.  What exactly do you want to reorder?  I mean, this program is meant
> to dump the complete contents to stdout (whether you redirect it to a file
> or edit it with sed does not concern this program).  It does that.

fast-import does not need to take a complete repository as input, but
can also update lots of branches incrementally, all from one process.
Likewise, it would be nice to have a program  that can also dump small
bits of information.

Maybe I'm misunderstanding you, but fast-export just does not seem a
mirror of fast-import; perhaps you can name it 'dump-all' or
something?

> Maybe you want to specify if all blobs should be output first, and then
> the commits?  Or files should be used?  But all of these things seem to be
> useless to me.

No, I want the program to wait for me to tell it what
blobs/commits/trees I want. The commit I want to see secondly may
depend on the output I read in the first request blob. Right now, for
each data dependency I have to start a new git process.

> > Besides being a nuisance, I actually run git on NFS, and every git
> > process has to go to NFS a couple times to retrieve the same
> > information. This has a noticeable performance impact.
>
> Why don't you just work on a local clone?  If it is really performance
> critical, and I/O is an issue, you are better off working in a tmpfs.

In a company setting, NFS is the easiest way to share information with
colleagues without breaking access control and making our security
staff nervous.  It's also snapshotted and backed up automatically.

> > It would make my life a lot easier if I could simply open a pipe to a
> > single process for the duration of the script, and do all my queries to
> > this one process.  Of course, if the repository is changed by another
> > process, I would have to restart it, but that's manageable.  I could
> > even write a nice Python class that runs both fast-import and
> > fast-export. I could then have an efficient Python interface to a
> > git-repository, without needing any library wrapping.
>
> There is a minimal python wrapper to libgit-thin, which was one of our
> GSoC projects.  You might want to look at this if you are really that
> unhappy with the existing framework.

What's the status of this?  I prefer not to diverge from mainline too much.

-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen