Re: An idea: maybe Git should use a lock/unlock file mode for problematic files? [Was: Re: after first git clone of linux kernel repository there are changed files in working dir]

[Daniel Barkalow <barkalow@iabervon.org>]

On Wed, 21 Jan 2009, John Chapman wrote:

> On Tue, 2009-01-20 at 15:11 -0500, Daniel Barkalow wrote:
> <snip>
> > 
> > The hard part is actually identifying what the user's filesystem has done. 
> > There's pretty good internal support for git knowing that, for a 
> > particular entry, the filesystem should not be consulted for information. 
> > I don't think anyone's come up with a suitably cross-platform and 
> > automatic way to figure out what's happened when git tries to write to a 
> > particular filename and the system decides it is the same as some other 
> > filename or it decides to use a different filename instead.
> 
> This would only need to interact with the git status command, wouldn't
> it?

The information is needed in a bunch of commands (diff and add, for 
example), but I believe that's already taken care on. The problem is 
getting it set automatically instead of having git not notice that the 
filesystem isn't doing what it expects.

> > Of course, it is reasonably likely that a project whose files can't all be 
> > checked out can't be dealt with anyway on that platform (IIRC, the Linux 
> > kernel build system assumes that it can create both .S and .s files, so it 
> > won't build on FAT). So nobody's been sufficiently motivated to try to 
> > implement a fix.
> 
> I doubt the kernel builds on windows, but this would allow a windows
> user to modify such files, perhaps in preparation for a patch that does
> allow the kernel to be built on windows?
> (Of course, we're using the kernel here as an example, right?  Nobody
> would be insane as to want to use windows for that!)
> 
> See, a very annoying thing about windows is that it is quite simple for
> a team to commit two files that differ by case alone to a git
> repository.

My impression was that this didn't happen in practice, because teams
would tend to not have two people create the same file at the same time, 
but with different cases, and people interacting with the same file at 
different times would use whatever case it was introduced with.

I think I'd only heard about problems for people who were using 
filesystems with different properties than what the rest of the developers 
on the project were using.

But I've only ever worked on projects that expect case-sensitivity, and 
mostly on projects that have a standard style that prevents duplication.

	-Daniel
*This .sig left intentionally blank*