Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

From: Duy Nguyen <pclouds@gmail.com>
Date: Sep 19, 2018, 16:12 UTC
Message-ID: <CACsJy8A3QCYY6QeJQYkbCKYh=7Q7pj=rer_OQHLGoAMqTNomNA@mail.gmail.com>
In-Reply-To: <20180918231903.GA30695@sigill.intra.peff.net>

On Wed, Sep 19, 2018 at 1:19 AM Jeff King <peff@peff.net> wrote:

Show 18 quoted lines

>
> 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.

-- 
Duy