On Sun, Feb 14, 2010 at 11:16 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > On Sun, 14 Feb 2010, Avery Pennarun wrote: >> In fact, arguably you should prevent git-add from adding large files >> at all, because at least then you don't get the repository into a >> hard-to-recover-from state with huge files. (This happened at work a >> few months ago; most people have no idea what to do in such a >> situation.) > > Git needs to be fixed in that case, not be crippled. That would be ideal, but is more work than disabling imports for large files by default (for example), which would be easy. In any case, my solution at work was to say "if it hurts, don't do that" and it seems to have worked out okay for now. >> For my own situation, I think I'm more likely to (and I know people >> who are more likely to) try storing huge files in git than I am likely >> to modify a file *while* I'm trying to store it in git. > > And fancy operations on huge files are pretty unlikely. Blame, diff, > etc, are suited for text file which are by nature relatively small. > And if your source code is all pasted in one single huge file that Git > can't handle right now, then the compiler is unlikely to cope either. Well, I'm thinking of things like textual database dumps, such as those produced by mysqldump. It would be nice to be able to diff those efficiently, even if they're several gigs in size. bup's hierarchical chunking allows this. >> > The other way to handle huge files is to split them into chunks. >> > http://article.gmane.org/gmane.comp.version-control.git/120112 > > No. The chunk idea doesn't fit the Git model well enough without many > corner cases all over the place which is a major drawback. I think that > was discussed in that thread already. > >> I have a bit of experience splitting files into chunks: >> http://groups.google.com/group/bup-list/browse_thread/thread/812031efd4c5f7e4 Note that bup's rolling-checksum-based hierarchical chunking is not the same as the chunking that was discussed in that thread, and it resolves most of the problems. Unless I'm missing something. Also note that bup just uses normal tree objects (for better or worse) instead of introducing a new object type. >> It works. Also note that the speed gain from mmap'ing packs appears >> to be much less than the gain from mmap'ing indexes. You could >> probably sacrifice most or all of the former and never really notice. >> Caching expanded deltas can be pretty valuable, though. (bup >> presently avoids that whole question by not using deltas.) > > We do have a cache of expanded deltas already. Yes, sorry to have implied otherwise. I was just comparing the performance advantage of the delta expansion cache (which should be a lot) with that of mmaping packfiles (which probably isn't much since the packfile data is typically needed in expanded form anyway). >> I can also confirm that streaming objects directly into packs is a >> massive performance increase when dealing with big files. However, >> you then start to run into git's heuristics that often assume (for >> example) that if an object is in a pack, it should never (or rarely) >> be pruned. This is normally a fine assumption, because if it was >> likely to get pruned, it probably never would have been put into a >> pack in the first place. > > Would you please for my own sanity tell me where we do such thing. I > thought I had a firm grip on the pack model but you're casting a shadow > of doubts on some code I might have written myself. Sorry, I didn't hunt down the code, but I ran into it while experimenting before. The rules are something like: - git-prune only prunes unpacked objects - git-repack claims to be willing to explode unreachable objects back into loose objects with -A, but I'm not quite sure if its definition of "unreachable" is the same as mine. And I'm not sure rewriting a pack with -A makes the old pack reliably unreachable according to -d. It's possible I was just being dense. - there seems to be no documented situation in which you can ever delete unused objects from a pack without using repack -a or -A, which can be amazingly slow if your packs are huge. (Ideally you'd only repack the particular packs that you want to shrink.) For example, my bup repo is currently 200 GB. Anyway, I didn't have much luck when playing with it earlier, but didn't investigate since I assumed it's just a workflow that nobody much cares about. Which I think is a reasonable position for git developers to take anyway. Have fun, Avery -- 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