Jeff King <peff@xxxxxxxx> 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 ;-). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html