Hi,

On Thu, 22 Nov 2007, Han-Wen Nienhuys wrote:

quoted text
> 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?

It is a mirror.  It does not necessarily dump all.

quoted text
> > 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.

It does not seem like you want a mirror of fast-import, but rather a 
driver.  You might be happy to hear that you can do that already.  Today.
However, you probably want to query different programs about certain 
states of the repository.  This will not change.

quoted text
> > > 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.

So?

How does that prevent you from following my suggestion to do the intensive 
tasks locally, and push when you finished?

Ciao,
Dscho

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html