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]

["Alex Riesen" <raa.lkml@gmail.com>]

2009/1/20 Daniel Barkalow <barkalow@iabervon.org>:
> 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.

It will and does happen in practice (annoingly too often even). Not with Git
yet (with Perforce), where people do "branching" by simply copying things
in another directory (perforce world does not know real branches),
renaming files randomly, and putting the new directory back in the
system (or maybe it is the strange tools here which do that - often
it is the first character of a directory or file which gets down- or up-cased).
As Perforce itself is case sensitive (like Git), using of such branches
is a nightmare: the files get overwritten in checkout order which is
not always sorted in predictable order. Combined with case-stupidity
of the file system the working directories sometimes cause "interesting
time" for unlucky users.
Luckily (sadly) it is all-opening-in-a-wall shop, so the problem with "fanthom"
files is rare (it is hard to notice) for most. Which actually makes it more
frustrating when the real shit happens.

And it will happen to Git as well, especially if development go crossplatform.
It is not that hard to accidentally rename a file on case-sensitive file system,
"git add *" it and commit without thinking (that's how most of software
development happens, come to think of it).