Carl Worth <cworth@xxxxxxxxxx> wrote: > On Thu, 14 Dec 2006 22:25:30 -0500, Shawn Pearce wrote: > > I saw three things happen to poor jwatt that really threw him for > > a loop, and I think they are all more likely related to Git than > > to the Cairo project specifically: > > Yes. Also a fourth one was a filesystem case-insensitivity issue. We > recently imported an external library into cairo that had some > filenames with capital letters. We then renamed them to the > all-lowercase filenames we like. Poor jwatt was unlucky enough to have > cloned with a capitalized filename, and then was trying to pull the > latest with the lowercase filename and he got: > > fatal: Untracked working tree file 'test/pdiff/lpyramid.h' > would be overwritten by merge > > This was in some sense worse than the other problems since it stopped > him cold and gave him no idea what was wrong nor how to fix it. This is a huge problem on filesystems where case does not matter (FAT, Mac OS X's HFS+, NTFS). We really should put something into git to detect this when it happens and help the user get out of the box they have worked themselves into. > > * His user.name/user.email is probably not what he wanted; > > > > * His Cygwin/Windows system made some *.c/*.c files 0755 without > > him realizing it; > > Those two issues did silently put garbage in the commits. I don't know > how to best fix the name/email thing. Maybe on the first commit with > no user.name and user.email configuration git could create them, > announce them to the user, and instruct them on how to change them: > > No name or email configuration exists. Using: > > U-JONATHAN-X60S\jonathan <jonathan@Jonathan-X60s.(none)> > > You can change these with the following commands: > > git repo-config user.name Your Name > git repo-config user.email user@xxxxxxxxxxx > > And maybe mention --global as well. I've been thinking that is the right thing to do, somewhere in git-commit, but I can't decide if its best to save that per-repository or per user, or be interactive and get confirmation from the user, or just display it and hope the user noticed. > As for the filemode setting, shouldn't that be configured by default > the right way for Windows git? No. The problem is Git tries to be smart and see if filemode works by chmodding the config file and then looking to see if that worked the way we expected it to. It usually does on Cygwin when using NTFS. But then if you edit a file non-executable file with a native Windows application Cygwin may suddenly think its executable again, and now our core.filemode=true guess isn't actually right anymore. We probably should just hardcode core.filemode to false on Cygwin. If the user actually wants core.filemode to be true on Cygwin then he/she will probably also know enough about this issue with native Windows applications that the additional hurdle of turning on the option by hand won't be a big one for them. > > * gitweb made it appear as though a whole lot of Carl's recent > > work was somehow undone in the merge. > > That looks like a simple gitweb bug. None of the other tools, (gitk, > git log -p), consider a trivial merge commit like this as having > anything interesting in it worth displaying. Right. gitweb is doing `diff HEAD^1 HEAD` which is quite wrong on a merge commit. Especially here where the trunk was pulled into the topic branch, rather than the topic branch being pulled into the trunk. -- Shawn. - 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