Re: [RFH] "git reset --hard" broken???

From: Jeff King <peff@peff.net>
Date: Jul 1, 2013, 21:47 UTC
Message-ID: <20130701214756.GA13962@sigill.intra.peff.net>
In-Reply-To: <7vli5qezqj.fsf@alter.siamese.dyndns.org>

On Mon, Jul 01, 2013 at 02:28:52PM -0700, Junio C Hamano wrote:

Show 14 quoted lines

> I have no time to dig this down, but I just noticed this by accident:
> 
> 	$ make
>         $ cd t
>         $ sh ./t7011-skip-worktree-reading.sh -d
>         $ cd trash*.t7011*
>         $ git reset --hard HEAD
>         error: Entry '1' not uptodate. Cannot merge.
> 	fatal: Could not reset index file to revision 'HEAD'.
> 
> which looks quite bogus.  "reset --hard" is meant to be the last
> resort "no matter what, please match the working tree to the commit"
> and should not ever error out with "not uptodate Cannot merge"
> message.

Yeah, I would agree. I do not think this is a new breakage. It behaves the same way all the way back to v1.7.0 (the first commit with t7011). Trying to go back further (by snapshotting the state of the trash directory and just running the reset on it) doesn't work, as older versions do not understand the skip-worktree bit.

I'm not sure yet if it's just a problem with skip-worktree entries, or if you can trigger the problem another way, though.

-Peff