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

[Jeff King <peff@peff.net>]

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

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