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: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 20, 2009, 20:11 UTC
Message-ID: <alpine.LNX.1.00.0901201441480.19665@iabervon.org>
In-Reply-To: <20090120105228.xbo3gyc0odwcgcsc@webmail.fussycoder.id.au>

On Tue, 20 Jan 2009, thestar@fussycoder.id.au wrote:

Show 23 quoted lines

> Quoting Hannu Koivisto <azure@iki.fi>:
> <snip>
> > Kernel source contains pairs of files whose names differ only by
> > case.  Windows cannot store such pairs (at least by default) and
> > apparently there is no support for such a situation in git so
> > you'll only get one file from each pair to your workspace and the
> > other file is shown as modified.
> 
> Could git be modified to allow such repositories to be used on windows  
> by locking files that are problematic, for example, a given repository  
> could have files 'AAA' and 'aAa'.
> 
> The one that correctly represents the on-disk file would be 'open for  
> edit', while the other file would be locked.  To edit the other file,  
> the existing file would need to be locked, and then the other file  
> would then need to be open for edit.
> 
> This could even be extended to allow one to "open file AAA for edit as  
> aAa.v2', giving the file an alternate name.
> 
> Such a workflow would only need to be used for such files, and could  
> also be used when there are incompatible file names for that given  
> partition type.

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.

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.

	-Daniel
*This .sig left intentionally blank*