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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]