Re: git reset --hard isn't resetting

From: Avery Pennarun <apenwarr@gmail.com>
Date: Aug 6, 2008, 18:02 UTC
Message-ID: <32541b130808061102q752076a8ydc02fef4e799491f@mail.gmail.com>
In-Reply-To: <1c5969370808060941q59cb8f7fhabee3ef3c5107715@mail.gmail.com>

On 8/6/08, Matt Graham <mdg149@gmail.com> wrote:

Show 8 quoted lines

>  I'm using a git svn tree in Cygwin.  I tried doing an svn rebase and
>  got in some weird state with local changes I can't get rid of.  It's
>  not an issue w/ the same repository on my linux machine.
>
>  git reset --hard
>  toggles 4 files between capitalization.  The files don't appear to
>  have changed case in svn, but it's a huge repository and not easy to
>  determine with certainty.

Try:
   git log --name-only
to see which patches change which files.  It's a virtual certainty
that they were renamed in svn at some point.

git doesn't handle case-munging filesystems perfectly, and gets into the situation you describe. First, you need to figure out whether you have files with *both* cases accidentally added to your index (if git reset toggles the capitalization, this is almost certainly the case):

    git ls-tree HEAD

If you see the same files with different case, that's your problem.

Now just 'git rm' the ones with the case you don't want, and commit the result. (Do *not* use commit -a!) 'git status' will give you some funny messages indicating that files you *didn't* 'git rm' have gone away in the filesystem; it's true, of course, but don't worry about that. Now 'git reset --hard HEAD' and you should be okay.

I'm not really sure what git should do better in this case, although the current behaviour is obviously a bit confusing.

Have fun,

Avery