On Wed, Sep 11, 2013 at 11:14:57AM -0700, Junio C Hamano wrote:
> John Keeping <j...@keeping.me.uk> writes:
> > On Wed, Sep 11, 2013 at 10:08:18AM -0700, Junio C Hamano wrote:
> >> 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"?
> > Duy's suggestion below is necessary to avoid this then I think - we'll
> > die if the user has a corrupt index and gives a path with a trailing
> > slash, but without that path we won't try to load the index.
> Sorry, but I don't quite follow. Isn't "git reset --soft <path>" a
> nonsense, with or without a trailing slash at the end of <path>?
Yes, but my point was that providing the user doesn't give a path with a
trailing slash we will get past the option parser if we take the
However, I think we do do a read_cache when using "reset --soft" since
we go through builtin/reset.c::die_if_unmerged_cache() which dies if
read_cache fails. So I don't think we are losing anything by moving
this check earlier.
> >> > 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