On Tue, 16 Oct 2007, Johannes Schindelin wrote:

quoted text
> Hi,
> 
> [culled make-w32, as per explicit request]
> 
> On Tue, 16 Oct 2007, Eli Zaretskii wrote:
> 
> > > Date: Tue, 16 Oct 2007 01:56:46 -0400 (EDT)
> > > From: Daniel Barkalow <barkalow@iabervon.org>
> > > cc: raa.lkml@gmail.com, Johannes.Schindelin@gmx.de, ae@op5.se, 
> > >     tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org
> > > 
> > > Ah, that's helpful. We don't actually care too much about the 
> > > particular info in stat; we just want to know quickly if the file has 
> > > changed, so we can hash only the ones that have been touched and get 
> > > the actual content changes.
> > 
> > As I wrote in my other message, using native APIs improves performance 
> > by at least a factor of two.
> 
> Somehow this does not appeal to my "portability is good" side.  You know, 
> if we had to do such trickeries for every platform we support, we'd soon 
> be as big as Subversion *cough*.

I think that it would be a worthwhile project, from the point of view of 
making the code easier to follow and making the internal APIs clearer, to 
organize git's source to abstract the object database to read_sha1_file(), 
has_sha1_file(), hash_sha1_file(), and write_sha1_file() as the arbiters 
of what is in the local database (with other functions public as support 
for over-the-wire protocols, which may, by not-really-coincidence, by used 
for local storage as well); then Windows could have an entirely different 
storage mechanism that doesn't rely on filesystem metadata speed.

It would also be worthwhile to untangle the index's stat cache aspects and 
its tree-object-related aspects, so that there can be a platform- and 
repository-specific concept of how to handle the working area, and then 
Windows could do different stuff for the default case of setting up a 
directory on the local filesystem.

	-Daniel
*This .sig left intentionally blank*
-
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