On Wed, Sep 19, 2018 at 06:12:23PM +0200, Duy Nguyen wrote: > On Wed, Sep 19, 2018 at 1:19 AM Jeff King <p...@peff.net> wrote: > > > > On Tue, Sep 18, 2018 at 12:36:06PM -0700, Jacob Keller wrote: > > > > > > I like that, too. It's a little more costly just because it may involve > > > > object-db writes, but I think in most cases it would be fine. I almost > > > > always "git stash" away discarded changes these days instead of "git > > > > reset --hard", because it effectively provides this kind of log. > > > > > > Obviously we do eventually turn the index into a tree, which is used > > > by the commit. Would it be possible to simply somehow store these > > > trees, and have commands which blow the tree away simply instead, save > > > it? I'm not sure how costly that is. > > > > For an up-to-date index with the cache-tree extension, this should be > > pretty cheap. Even for a partially-staged index, where we already have > > the blob in the object database, it should just incur the tree > > computation (and parts you didn't touch would hopefully have an > > up-to-date cache-tree). > > Just FYI. I wanted to get at least pruning support in place before > posting another RFC. But right now I'm going without cache-tree. > Whenever a file is updated, the _blob_ hashes are recorded in the > index log (one line per update, same as reflog format) and the > description part of the line is the updated path. > > This is simpler to do, and we can still reconstruct a tree/commit in > memory if we need to (but not whole tree snapshots; but I don't think > that would be very useful). But maybe cache-tree approach is better. > We will see.
Oh, interesting. Sort of a hybrid approach. :) That makes sense, and I don't see any reason it wouldn't work. -Peff
