Whether it makes sense for a blob to be stored as bare object or not. Into hash lookup and storage, where the storage part needs a way of telling git/objects/bare/XX/YY inĮxamples (where XX and YY are the first two and the rest of the object'sĪ first implementation would be relatively easy, it would just need to hook All that bare objects would need is aĭistinct path in the hierarchy, I'll use. Here: A bare object is always of type blob and uncompressed, thus its sizeĬan be seen from the file system. There should be a third kind of objects that will be called "bare objects"
Zlib-compressed, and pack files (which can contain more than one object andīoth forms of compression perform poorly on blobs, especially when they areĪlreay compressed, like media data typically is. git/objects//), which are prefixed with type and length and then First stepsĬurrently, Git has two ways of storing an object: regular objects (in Unmodified when one version (the checkout) gets changed. System's ability to present the same data at different places (in theĬommitted object store and the checkout) and still leave the original version When working on a copy-on-write file system Changes I'd like to see in Git Storing objects in a COW friendly way GUI and metadata management) than at actually storing the data, where a Git-annex works around those shortcomings,īut is better at tracking storage locations (and "recently" also providing a Immediately accessible in the file system - if you manage your photoĬollection in git, the disk space used is roughly twice the size of your bare Git is great for version control, but is inefficientįor storing large or many binary blobs (videos, photos) in a way they are Space efficient Git checkouts using COW file systems The issue
0 kommentar(er)
