On Thu, Aug 7, 2008 at 9:06 PM, Matt Graham <mdg149@xxxxxxxxx> wrote: > On Wed, Aug 6, 2008 at 2:02 PM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: >> 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. Hmm. Well, one possibly important thing is that if you take a diff between the version before the old files were removed, and the version after the new files were added, it will *look* like a rename because git doesn't look at the intermediate revisions. And note that this sort of thing will be happen if you "git checkout" the before and after versions. > 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 :) Beware that svn doesn't reliably sort its filename lists, so you might find that two different files in the *same* directory are in totally different places in the list; perhaps you missed a filename that way. Good luck, Avery -- 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
