Re: git reset --hard isn't resetting

> On Thu, Aug 7, 2008 at 9:06 PM, Matt Graham <mdg149@gmail.com> wrote:
> > On Wed, Aug 6, 2008 at 2:02 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> > 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.
> 
> Did your Linux machine import the data using git-svn, or did it clone
> a repo from Windows that imported using git-svn?
> 
> I can imagine a situation where git-svn on Windows could get confused
> and add the wrong filenames (although it would be kind of unlikely if
> they really were removed in one revision, then readded in another; why
> would git-svn even think about the old names in that case?).  However,
> there's no explanation for a Linux system introducing such a mistake,
> since the two files are just unrelated as far as Linux is concerned.

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

> If your git-svn repo doesn't reflect *exactly* the set of files in
> your real svn repo, then you've hit a pretty bad bug and you're almost
> certainly going to have problems with dcommit.  On the other hand,
> you're unlikely to manage to screw up your svn repo, assuming the
> files you deleted were the ones that weren't supposed to be there;
> "extra deleting" them from svn wouldn't be dangerous.  I'd expect git
> svn dcommit to just fail with a weird error.

> >> 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.
> 
> Since this seems virtually impossible, it would be nice if you could
> double check your SVN repo to make sure the problem really doesn't
> exist there in *any* version.  It just doesn't seem likely that git
> would have had this problem if the files were cleanly removed in one
> revision, then added in a later one.  I could imagine it if they were
> renamed all in one revision, though, or if there was *ever* an svn
> revision where both files existed at once.  In all those cases we
> effectively have a bug in git-svn, but at least in the latter cases
> it's an explainable one :)