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

Junio C Hamano· Jul 1, 2013, 21:28 UTC · lore

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.

Interestingly, you can do this to work it around, though:

        $ cd t
        $ sh ./t7011-skip-worktree-reading.sh -d
        $ cd trash*.t7011*
	$ git reset
        $ git reset --hard HEAD
        HEAD is now at .... init

Jeff King· Jul 1, 2013, 21:47 UTC · re: Junio C Hamano · lore

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

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