Re: git reset --hard isn't resetting

["Matt Graham" <mdg149@gmail.com>]

On Wed, Aug 6, 2008 at 2:02 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> 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.

They weren't "renamed".  Further investigation w/ the hated svn tools
showed that the upper case was removed, then many commits later, the
lowercase was added.

> 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.

Indeed that was the problem.  In fact, l now noticed that my linux
machine has both versions as well.  Being case sensitive, it didn't
mind and the problem wasn't obvious.

> 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.

This worked fine exactly as you said.  I'm curious what will happen when I do
   git svn dcommit
These aren't my files and I'm sort of using git svn on the sly.  I'd
prefer to not have something weird happen to the svn repository due to
this.  Due to the schedule, our tolerance for screwing things up b/c I
want to use git will be low.  And my argument that we should have used
git from the outset probably won't help any.

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

Yes, if SVN is going to have both versions, it's understandable that
git wouldn't know what to do.  Unfortunately, it looks like SVN only
had one version at a time.  So it seems git somehow revived the
uppercase version when the lowercase one was readded through git svn.

This happened on both the cygwin and linux versions, although it only
caused an obvious problem on the cygwin version.  I don't know git
well enough to speculate why this happened, but it looks like it's a
real bug that shouldn't have happened in this case.

On cygwin I'm using 1.5.5.1 and the repository only used that version.
On linux, I currently have 1.6.0.rc0.79.gb0320 but the repo may have
been originally cloned w/ earlier versions.