On Sun, 9 Nov 2008, Kai Blin wrote: > On Saturday 08 November 2008 16:31:04 Jakub Narebski wrote: >>>> * Tim: Git as a Media Repository >>>> http://www.thousandparsec.net/~tim/media+git.pdf >>> >>> This has kicked off some mailing list discussion; I think this can be >>> a major weak point for git, since checking out only a subtree (and >>> only the latest revision) is the common SVN way, which copes with >>> media repositories and the like just fine. >> >> Well, you can workaround this weakness by (ab)using submodules... >> ...and one should always remember that casual partial checkouts >> interfere a bit with whole-tree commits. > > Interesting. How would you use submodules to work around the fact that binary > file changes diff very bad and produce huge histories with basically no value > for the user of the working copy? Can you do this from a GUI, easily? We're > talking about media repositories here, so our users are artists. What I meant here (but perhaps was not clear) was (ab)using submodules to allow to have full working repository without large [media] files both in object database (repository) and without them checked out. The workaround is to put all large files for example in 'media/' folder, and make this folder be submodule. Each clone of repository can have this 'media' submodule either present (both in object database, although usually separate from main project object database), or not present (not cloned and not checked out). As to submodules UI and GUI support for submodules... currently it is unfortunately lacking. Note that I explicitly mentioned that (ab)using submodules to better deal with large files is _workaround_, and not _solution_. Lazy clone in version proposed by Tim is IMHO correct solution. P.S. Could anybody document at last `delta' gitattribute? P.P.S. You can have separate diff driver for binary files, but I don't know anyone who uses for example some such for images... -- Jakub Narebski Poland -- 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
