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

From: Jeff King <peff@peff.net>
Date: Sep 18, 2018, 23:19 UTC
Message-ID: <20180918231903.GA30695@sigill.intra.peff.net>
In-Reply-To: <CA+P7+xqzN5M6VgQqCNAAsmwYRmnoSVsAvdES7aK2fKf9P-f4fg@mail.gmail.com>

On Tue, Sep 18, 2018 at 12:36:06PM -0700, Jacob Keller wrote:

Show 9 quoted lines

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

Where it gets expensive is when you are throwing away working-tree changes, and you have to re-hash those objects. Conceptually that's not much worse than just calling `git add`, but there are corner cases (e.g., imagine you keep a 1GB clone of another project in an ignored directory, and then `git clean -dx` wants to `git add` all of it).

-Peff