Re: speed of git reset -- file
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 31, 2011, 23:39 UTC
- Message-ID
- <7v62oqignm.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20110531212639.GA13234@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... Unfortunately this seems to trash the index (see the > comment there), and we end up having to refresh it.
I think you are reading it wrong. Yes, diff-index will contaminate the in-core index when it tries to find out which paths are to be reset, the "discard" refers to the fact that it would be useless to add_cache_entry() or remove_file_from_cache() to the in-core index without reading the in-core index afresh.
So we restart from a freshly read index (see read_cache() at the beginning of update_index_from_diff() callback) with all the stat information just as fresh as you used to have before you ran this "git reset", and then we update the paths that the internal diff-index found in the in-core index.
"git reset" has always refreshed the index. If somebody _really_ wants to introduce a slight inconsistency to "git reset" so that only in "per-path" mode it doesn't refresh, the call to refresh_index() can easily be removed from update_index_refresh(). There is no "we end up having to".
IOW, we refresh by choice, design and inertia ;-).