Re: Handling large files with GIT

On 2/15/06, Sam Vilain <sam@vilain.net> wrote:

I think Junio & Linus are talking about alternative mergers, something that can be called instead of git-read-tree -m (which is the way merges seem to kick off). Or perhaps an additional flag to git-read-tree to be used in conjunction with -m, something like --optimize-for-identity that lets git-read-tree know to do a first pass keying things on file identity rather than file path.

So we are _not_ touching the object database, at all. Only optimising merges for very large trees there mv is a popular operation. All the cases you discuss can be tackled very efficiently without making *any* change to the object database.

Oh, I don't need it at all. It's just that there's been some lazy talk of tracking mboxes and maildirs with git, and look where it's led. Blame Roland Stigge who got me started down this track.

I'm sure it's because the other optimisations are a lot harder to tackle ;-) though Linus mentions that it'd be trivial for git-read-tree -m to detect unchanged directories and perhaps do things a bit faster. Not as revolutionary as an --optimize-for-identity but not as risky either.

In any case, don't count in me for any of this git-checkout hacking. I know better than start learning C posting patches to *this* list.

cheers,

martin