Duy Nguyen <pclo...@gmail.com> writes:

> reset --soft does not go through these code paths (i.e. it does not
> need index at all). If we fail to load index index in "reset --soft" I
> think it's ok to die(). Corrupt index is fatal anyway.

Do I smell a breakage here?  Isn't "reset --soft HEAD" (or some
known good commit) a way to recover from a corrupt index?

If that is the case, I do not think it is OK at all.  What do we
suggest as an alternative?  "rm .git/index && read-tree"?

> But "reset
> --soft" now has to pay the cost to load index, which could be slow
> when the index is big. Assuming nobody does "reset --soft" that often
> I think this is OK.
> Alternatively we could load index lazily in _CHEAP code only when we
> see trailing slashes, then replace these read_cache() with
> read_cache_unless_its_already_loaded_earlier() or something.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to