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

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

[Junio C Hamano]

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

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

[Jeff King]

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

> 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