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]

From: John Chapman <thestar@fussycoder.id.au>
Date: Jan 20, 2009, 21:28 UTC
Message-ID: <1232486929.4179.7.camel@therock.nsw.bigpond.net.au>
In-Reply-To: <alpine.LNX.1.00.0901201441480.19665@iabervon.org>

On Tue, 2009-01-20 at 15:11 -0500, Daniel Barkalow wrote: <snip>

Show 8 quoted lines

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

Show 6 quoted lines

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

Was just an idea, really.