* Jeff King (peff@xxxxxxxx) [110321 08:00]: > I'm not exactly clear on what you want to implement. Neither was I, that's why I sent the vague email :-) I think I have a better understanding now of what would need to be done: * reading unadorned blobs, as a last resort if the object isn't found elsewhere. use reflink (if available) to copy an unadorned blob into the working directory * writing unadorned blobs, according to size limit / attribute. this also means computing the sha1 for the blob without reading the entire thing into memory all at once. * leaving unadorned blobs alone in gc, unless explicitly told not to * supporting the easy cases of binary diffs for git-upload-pack. it shouldn't have to send an entire copy of a huge file if only a little bit of the file changed. This could use fiemap, or maybe bup's rolling checksum, or maybe either, depending on what's available. * support for applying those binary diffs directly to the on-disk reflink. this could probably just mmap the file and call patch-delta. I think these features would make some, but not all of the big file use cases much more usable. What do you think? -- 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