Avery Pennarun <apenwarr@xxxxxxxxx> wrote: > 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: > > 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. git-svn *never* touches the working tree on the filesystem directly. It only does so via git-rebase or git-reset when dcommiting. That said, I have no idea (nor interest in knowing the gory details) as to how/if git works on case-insensitive filesystems. git-svn certainly has never done any special with them; git-svn itself will always take path names that SVN provides as-is. > > 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. Matt: try using --dry-run with dcommit to figure out what it's doing. Whenever git-svn dcommits to SVN, it reads all of its pathnames from already-committed history in git, so it's unlikely to be affected by issues on the local filesystem. However the rebase/reset after dcommit could be problematic. --no-rebase can probably be used with dcommit here to avoid issues with rebase. That said, I take no responsibility for any screwups that may happen. (especially since Windows is involved). > 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. git-svn should always die/croak immediately if it notices anything wrong. Again, there is no guarantee nor warranty :) > >> 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 :) One possibility is that the SVN libraries themselves fail to report case-changing renames on Windows when git-svn is fetching. And then (hypothetically) git on cygwin tries to do something smart somewhere with case-insensitive paths. The above is purely a hunch, anybody else want to investigate that possibility? -- Eric Wong -- 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
