On Fri, 24 Oct 2008, Nanako Shiraishi wrote: > Quoting Daniel Barkalow <barkalow@xxxxxxxxxxxx>: > > > On Wed, 22 Oct 2008, Edward Ned Harvey wrote: > > > >> Out of curiosity, what are they talking about, when they say "git is > >> fast?" Just the fact that it's all local disk, or is there more to it > >> than that? I could see - git would probably outperform perforce for > >> versioning of large files (let's say iso files) to benefit from > >> sustained local disk IO, while perforce would probably outperform > >> anything I can think of, operating on thousands of tiny files, because > >> it will never walk the tree. > > > > It shouldn't be too hard to make git work like perforce with respect to > > walking the tree. git keeps an index of the stat() info it saw when it > > last looked at files, and only looks at the contents of files whose stat() > > info has changed. In order to have it work like perforce, it would just > > need to have a flag in the stat() info index for "don't even bother", > > Are you describing the "assume unchanged bit"? Yes, but with the user write mode bit in the filesystem set to no-assume-unchanged, which is how Perforce users cope with it. I hadn't realized it had been implemented to get set on a per-file basis, rather than just as a global setting that caused it to not stat() anything except right when it was told to update. -Daniel *This .sig left intentionally blank* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
