Re: git reset --hard isn't resetting

["Avery Pennarun" <apenwarr@gmail.com>]

On 8/6/08, Matt Graham <mdg149@gmail.com> wrote:
>  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