All of lore.kernel.org
 help / color / mirror / Atom feed
From: Larry D'Anna <larry@elder-gods.org>
To: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: brtfs COW links and git
Date: Mon, 21 Mar 2011 22:44:21 -0400	[thread overview]
Message-ID: <20110322024421.GA15134@cthulhu> (raw)
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?

  reply	other threads:[~2011-03-22  2:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-19 20:15 brtfs COW links and git Larry D'Anna
2011-03-21 12:00 ` Jeff King
2011-03-22  2:44   ` Larry D'Anna [this message]
2011-03-22 11:43     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110322024421.GA15134@cthulhu \
    --to=larry@elder-gods.org \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.