From: Larry D'Anna <larry@elder-gods.org>
Date: Tue, 22 Mar 2011 02:44:21 GMT
Subject: Re: brtfs COW links and git
Message-ID: <20110322024421.GA15134@cthulhu>
In-Reply-To: <20110321120051.GG16334@sigill.intra.peff.net>

* Jeff King (peff@peff.net) [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?