{"thread":{"id":"16672","subject":"Re: after first git clone of linux kernel repository there are changed files in working dir","startedAt":"2008-12-10T18:22:46Z","lastAt":"2009-01-21T07:25:00Z","messageCount":16,"participants":["Brett Simmers","rdkrsr","Linus Torvalds","Boyd Stephen Smith Jr.","Giuseppe Bilotta","Nick Andrew","Hannu Koivisto","thestar@fussycoder.id.au","Daniel Barkalow","John Chapman","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"100974","messageId":"d304880b0812101022u2abe5d68ub3bda68ed39f830b@mail.gmail.com","threadId":"16672","inReplyTo":"d304880b0812101019ufe85095h46ff0fe00d32bbd0@mail.gmail.com","subject":"after first git clone of linux kernel repository there are changed files in working dir","fromName":"rdkrsr","fromEmail":"rdkrsr@googlemail.com","sentAt":"2008-12-10T18:22:46Z","receivedAt":"2008-12-10T18:22:46Z","isPatch":false,"sender":{"key":"rdkrsr@googlemail.com","avatar":null},"body":"I just fetched the sources without changing anything, but git diff\nshows, that there are changes that are not yet updated (changed but not\nupdated: use git add to ...). Why is it like that?\n\nI use msysgit on windows, maybe that is one reason?\n"},{"id":"97515","messageId":"e32b7bb40812101220s370a64f1n3f7ecb56dd352405@mail.gmail.com","threadId":"16672","inReplyTo":"d304880b0812101022u2abe5d68ub3bda68ed39f830b@mail.gmail.com","subject":"Re: after first git clone of linux kernel repository there are changed files in working dir","fromName":"Brett Simmers","fromEmail":"swtaarrs@gmail.com","sentAt":"2008-12-10T20:20:16Z","receivedAt":"2008-12-10T20:20:16Z","isPatch":false,"sender":{"key":"swtaarrs@gmail.com","avatar":null},"body":"On Wed, Dec 10, 2008 at 1:22 PM, rdkrsr wrote:\n> I just fetched the sources without changing anything, but git diff\n> shows, that there are changes that are not yet updated (changed but not\n> updated: use git add to ...). Why is it like that?\n>\n> I use msysgit on windows, maybe that is one reason?\n\nWhat are the filenames? I've seen git on Windows get confused if a\nrepository has two files that are the same except for the case of some\nof the letters (since both can't exist by default on NTFS).\n\n-Brett\n"},{"id":"97604","messageId":"d304880b0812110915o6968050cufbb1e29c8bcea984@mail.gmail.com","threadId":"16672","inReplyTo":"d304880b0812110142g41b80745ic09a7200e02dcdb0@mail.gmail.com","subject":"Fwd: after first git clone of linux kernel repository there are changed files in working dir","fromName":"rdkrsr","fromEmail":"rdkrsr@googlemail.com","sentAt":"2008-12-11T17:15:44Z","receivedAt":"2008-12-11T17:15:44Z","isPatch":false,"sender":{"key":"rdkrsr@googlemail.com","avatar":null},"body":"I'm sorry that I didn't answer to git mailing list address. So here\ncomes the email again.\n\n\nHere is what I did:\n\n$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/li\nt linux-2.6\nInitialize linux-2.6/.git\nInitialized empty Git repository in c:/Dokumente und Einstellungen/Ge\nEigene Dateien/vbox/linux-2.6/.git/\nremote: Counting objects: 980697, done.←[K\nremote: Compressing objects: 100% (161545/161545), done.←[K\nremote: Total 980697 (delta 818552), reused 978923 (delta 816954)←[K\nReceiving objects: 100% (980697/980697), 236.14 MiB | 90 KiB/s, done.\nResolving deltas: 100% (818552/818552), done.\nChecking out files: 100% (25254/25254), done.\n\n$ cd linux-2.6\n\n$ git status\n# On branch master\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n#\n# modified: Documentation/IO-mapping.txt\n# modified: include/linux/netfilter/xt_CONNMARK.h\n# modified: include/linux/netfilter/xt_DSCP.h\n# modified: include/linux/netfilter/xt_MARK.h\n# modified: include/linux/netfilter/xt_RATEEST.h\n# modified: include/linux/netfilter/xt_TCPMSS.h\n# modified: include/linux/netfilter_ipv4/ipt_CONNMARK.h\n# modified: include/linux/netfilter_ipv4/ipt_DSCP.h\n# modified: include/linux/netfilter_ipv4/ipt_ECN.h\n# modified: include/linux/netfilter_ipv4/ipt_MARK.h\n# modified: include/linux/netfilter_ipv4/ipt_TCPMSS.h\n# modified: include/linux/netfilter_ipv4/ipt_TOS.h\n# modified: include/linux/netfilter_ipv4/ipt_TTL.h\n# modified: include/linux/netfilter_ipv6/ip6t_HL.h\n# modified: include/linux/netfilter_ipv6/ip6t_MARK.h\n# modified: net/ipv4/netfilter/ipt_ECN.c\n# modified: net/ipv4/netfilter/ipt_TTL.c\n# modified: net/ipv6/netfilter/ip6t_HL.c\n# modified: net/netfilter/xt_CONNMARK.c\n# modified: net/netfilter/xt_DSCP.c\n# modified: net/netfilter/xt_MARK.c\n# modified: net/netfilter/xt_RATEEST.c\n# modified: net/netfilter/xt_TCPMSS.c\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\n2008/12/10 Brett Simmers :\n> On Wed, Dec 10, 2008 at 1:22 PM, rdkrsr wrote:\n>> I just fetched the sources without changing anything, but git diff\n>> shows, that there are changes that are not yet updated (changed but not\n>> updated: use git add to ...). Why is it like that?\n>>\n>> I use msysgit on windows, maybe that is one reason?\n>\n> What are the filenames? I've seen git on Windows get confused if a\n> repository has two files that are the same except for the case of some\n> of the letters (since both can't exist by default on NTFS).\n>\n> -Brett\n>\n"},{"id":"97607","messageId":"alpine.LFD.2.00.0812110934180.3340@localhost.localdomain","threadId":"16672","inReplyTo":"d304880b0812110915o6968050cufbb1e29c8bcea984@mail.gmail.com","subject":"Re: Fwd: after first git clone of linux kernel repository there are changed files in working dir","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-12-11T17:41:34Z","receivedAt":"2008-12-11T17:41:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 11 Dec 2008, rdkrsr wrote:\n>\n> I'm sorry that I didn't answer to git mailing list address. So here\n> comes the email again.\n\nYou have a broken filesystem.\n\n> $ git status\n> # On branch master\n> # Changed but not updated:\n> # (use \"git add ...\" to update what will be committed)\n> #\n> # modified: Documentation/IO-mapping.txt\n> # modified: include/linux/netfilter/xt_CONNMARK.h\n> # modified: include/linux/netfilter/xt_DSCP.h\n> # modified: include/linux/netfilter/xt_MARK.h\n> # modified: include/linux/netfilter/xt_RATEEST.h\n...\n\nThis is _exactly_ what happens if you try to develop the Linux kernel on a \ncase-insensitive filesystem. The kernel source tree has several files that \ndiffer only in case, eg\n\n\tDocumentation/IO-mapping.txt\n\tDocumentation/io-mapping.txt\n\tinclude/linux/netfilter/xt_tcpmss.h\n\tinclude/linux/netfilter/xt_TCPMSS.h\n\t..\n\nand if you try to check it out on a broken filesystem, then the second \nfile will overwrite the first one, and git will think that you have \nmodified it. \n\nOS X? Afaik, you can fix it by using NFS or UFS. And I think ZFS has a \ncase-sensitive mode too (and it may even be the default). In fact, I think \nnewer versions of OS X even allow that piece-of-sh*t HFS+ to be case \nsensitive (and thus make it much less sh*tty).\n\nOf course, there are reports of some Mac software breaking when they use a \nreal filesystem, but hey, what else is new?\n\n\t\t\tLinus\n"},{"id":"97608","messageId":"d304880b0812110958u3da52e4fs7e5154ebe9a353a@mail.gmail.com","threadId":"16672","inReplyTo":"alpine.LFD.2.00.0812110934180.3340@localhost.localdomain","subject":"Re: Fwd: after first git clone of linux kernel repository there are changed files in working dir","fromName":"rdkrsr","fromEmail":"rdkrsr@googlemail.com","sentAt":"2008-12-11T17:58:01Z","receivedAt":"2008-12-11T17:58:01Z","isPatch":false,"sender":{"key":"rdkrsr@googlemail.com","avatar":null},"body":"Thank you, Linus and Brett, for your answers.\n\nI'm not developing linux kernel, I just wanted to experiment with git.\nAnd then I didn't know if this is a normal behaviour of git. I'm using\nwindows xp and msysgit for this. And the file system is NTFS. I'm\nusing dual boot to sporadicly use linux and tried also linux in\nvirtual box. But both isn't really good. Maybe one day I dare to use\nlinux as my primary OS.\n\nRed\n\n2008/12/11 Linus Torvalds :\n>\n>\n> On Thu, 11 Dec 2008, rdkrsr wrote:\n>>\n>> I'm sorry that I didn't answer to git mailing list address. So here\n>> comes the email again.\n>\n> You have a broken filesystem.\n>\n>> $ git status\n>> # On branch master\n>> # Changed but not updated:\n>> # (use \"git add ...\" to update what will be committed)\n>> #\n>> # modified: Documentation/IO-mapping.txt\n>> # modified: include/linux/netfilter/xt_CONNMARK.h\n>> # modified: include/linux/netfilter/xt_DSCP.h\n>> # modified: include/linux/netfilter/xt_MARK.h\n>> # modified: include/linux/netfilter/xt_RATEEST.h\n> ...\n>\n> This is _exactly_ what happens if you try to develop the Linux kernel on a\n> case-insensitive filesystem. The kernel source tree has several files that\n> differ only in case, eg\n>\n> Documentation/IO-mapping.txt\n> Documentation/io-mapping.txt\n> include/linux/netfilter/xt_tcpmss.h\n> include/linux/netfilter/xt_TCPMSS.h\n> ..\n>\n> and if you try to check it out on a broken filesystem, then the second\n> file will overwrite the first one, and git will think that you have\n> modified it.\n>\n> OS X? Afaik, you can fix it by using NFS or UFS. And I think ZFS has a\n> case-sensitive mode too (and it may even be the default). In fact, I think\n> newer versions of OS X even allow that piece-of-sh*t HFS+ to be case\n> sensitive (and thus make it much less sh*tty).\n>\n> Of course, there are reports of some Mac software breaking when they use a\n> real filesystem, but hey, what else is new?\n>\n> Linus\n>\n"},{"id":"97614","messageId":"200812111423.28468.bss03@volumehost.net","threadId":"16672","inReplyTo":"d304880b0812110958u3da52e4fs7e5154ebe9a353a@mail.gmail.com","subject":"Re: Fwd: after first git clone of linux kernel repository there are changed files in working dir","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss03@volumehost.net","sentAt":"2008-12-11T20:23:28Z","receivedAt":"2008-12-11T20:23:28Z","isPatch":false,"sender":{"key":"bss03@volumehost.net","avatar":"https://gravatar.com/avatar/74fa10b37dfd44462a6a30c4d4e3bda26ab7991ddb0d8ab24b022714a8ecb918?d=mp&s=160"},"body":"On Thursday 2008 December 11 11:58:01 rdkrsr wrote:\n>I'm not developing linux kernel, I just wanted to experiment with git.\n>And then I didn't know if this is a normal behaviour of git. I'm using\n>windows xp and msysgit for this. And the file system is NTFS.\n\nYou might want to choose a more MS Windows-friendly codebase to test with. \nFor codebases without filenames that differ only in case, git should work \nfine on MS Windows. For codebases with filenames that differ only in case, I \ndon't know a VCS that will handle them well on MS Windows.\n-- \nBoyd Stephen Smith Jr.                     ,= ,-_-. =. \nbss03@volumehost.net                      ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' \nhttp://iguanasuicide.org/                      \\_/     \n"},{"id":"97619","messageId":"ghrti4$m53$1@ger.gmane.org","threadId":"16672","inReplyTo":"d304880b0812110958u3da52e4fs7e5154ebe9a353a@mail.gmail.com","subject":"Re: Fwd: after first git clone of linux kernel repository there are changed files in working dir","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-12-11T20:35:16Z","receivedAt":"2008-12-11T20:35:16Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Thursday 11 December 2008 18:58, rdkrsr wrote:\n\n> Thank you, Linus and Brett, for your answers.\n> \n> I'm not developing linux kernel, I just wanted to experiment with git.\n> And then I didn't know if this is a normal behaviour of git. I'm using\n> windows xp and msysgit for this. And the file system is NTFS. I'm\n> using dual boot to sporadicly use linux and tried also linux in\n> virtual box. But both isn't really good. Maybe one day I dare to use\n> linux as my primary OS.\n> \n> Red\n> \n> 2008/12/11 Linus Torvalds :\n>>\n>>\n>> On Thu, 11 Dec 2008, rdkrsr wrote:\n>>>\n>>> I'm sorry that I didn't answer to git mailing list address. So here\n>>> comes the email again.\n>>\n>> You have a broken filesystem.\n\nActually, the funny (in a grotesque kind of way) thing about NTFS\nis that it's a case-*sensitive* filesystem (in the sense that i\ncan legally hold files with names that differ only for the case),\nbut the Windows subsystems use it in case-preserving (but\ninsensitive) mode. It is possible to use NTFS case insensitively\nunder Windows, but it requires something such as the Interix\nsubsystem, and in Windows XP (and possibly later versions) it also\nneeds toggling a security policy that defaults to enforcing case\ninsensitivity for all subsystems.\n\nMaybe the Windows ports to git (at least the cygwin one, maybe?)\nmay be able to exploit this.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"97692","messageId":"20081212135134.GA18814@mail.local.tull.net","threadId":"16672","inReplyTo":"d304880b0812110958u3da52e4fs7e5154ebe9a353a@mail.gmail.com","subject":"Re: Fwd: after first git clone of linux kernel repository there are changed files in working dir","fromName":"Nick Andrew","fromEmail":"nick@nick-andrew.net","sentAt":"2008-12-12T13:51:34Z","receivedAt":"2008-12-12T13:51:34Z","isPatch":false,"sender":{"key":"nick@nick-andrew.net","avatar":"https://gravatar.com/avatar/85f25a67ca6eaa4016ed374f6d07f3cd853c886aeb7e1507eb7dbc47b00082fe?d=mp&s=160"},"body":"On Thu, Dec 11, 2008 at 06:58:01PM +0100, rdkrsr wrote:\n> windows xp and msysgit for this. And the file system is NTFS. I'm\n> using dual boot to sporadicly use linux and tried also linux in\n> virtual box.\n\nYou could use git inside your VirtualBox linux install.\n\n> But both isn't really good. Maybe one day I dare to use\n> linux as my primary OS.\n\nIt's not scary, really.\n\nNick.\n"},{"id":"101133","messageId":"83ocy3fmez.fsf@kalahari.s2.org","threadId":"16672","inReplyTo":"d304880b0812101022u2abe5d68ub3bda68ed39f830b@mail.gmail.com","subject":"Re: after first git clone of linux kernel repository there are changed files in working dir","fromName":"Hannu Koivisto","fromEmail":"azure@iki.fi","sentAt":"2009-01-19T13:36:04Z","receivedAt":"2009-01-19T13:36:04Z","isPatch":false,"sender":{"key":"azure@iki.fi","avatar":null},"body":"rdkrsr writes:\n\n> I just fetched the sources without changing anything, but git diff\n> shows, that there are changes that are not yet updated (changed but not\n> updated: use git add to ...). Why is it like that?\n>\n> I use msysgit on windows, maybe that is one reason?\n\nKernel source contains pairs of files whose names differ only by\ncase. Windows cannot store such pairs (at least by default) and\napparently there is no support for such a situation in git so\nyou'll only get one file from each pair to your workspace and the\nother file is shown as modified.\n\n-- \nHannu\n"},{"id":"101189","messageId":"20090120105228.xbo3gyc0odwcgcsc@webmail.fussycoder.id.au","threadId":"16672","inReplyTo":"83ocy3fmez.fsf@kalahari.s2.org","subject":"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]","fromName":"","fromEmail":"thestar@fussycoder.id.au","sentAt":"2009-01-19T23:52:28Z","receivedAt":"2009-01-19T23:52:28Z","isPatch":false,"sender":{"key":"thestar@fussycoder.id.au","avatar":null},"body":"Quoting Hannu Koivisto :\n\n> Kernel source contains pairs of files whose names differ only by\n> case. Windows cannot store such pairs (at least by default) and\n> apparently there is no support for such a situation in git so\n> you'll only get one file from each pair to your workspace and the\n> other file is shown as modified.\n\nCould git be modified to allow such repositories to be used on windows \nby locking files that are problematic, for example, a given repository \ncould have files 'AAA' and 'aAa'.\n\nThe one that correctly represents the on-disk file would be 'open for \nedit', while the other file would be locked. To edit the other file, \nthe existing file would need to be locked, and then the other file \nwould then need to be open for edit.\n\nThis could even be extended to allow one to \"open file AAA for edit as \naAa.v2', giving the file an alternate name.\n\nSuch a workflow would only need to be used for such files, and could \nalso be used when there are incompatible file names for that given \npartition type.\n"},{"id":"101292","messageId":"alpine.LNX.1.00.0901201441480.19665@iabervon.org","threadId":"16672","inReplyTo":"20090120105228.xbo3gyc0odwcgcsc@webmail.fussycoder.id.au","subject":"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]","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-01-20T20:11:28Z","receivedAt":"2009-01-20T20:11:28Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 20 Jan 2009, thestar@fussycoder.id.au wrote:\n\n> Quoting Hannu Koivisto :\n> \n> > Kernel source contains pairs of files whose names differ only by\n> > case. Windows cannot store such pairs (at least by default) and\n> > apparently there is no support for such a situation in git so\n> > you'll only get one file from each pair to your workspace and the\n> > other file is shown as modified.\n> \n> Could git be modified to allow such repositories to be used on windows \n> by locking files that are problematic, for example, a given repository \n> could have files 'AAA' and 'aAa'.\n> \n> The one that correctly represents the on-disk file would be 'open for \n> edit', while the other file would be locked. To edit the other file, \n> the existing file would need to be locked, and then the other file \n> would then need to be open for edit.\n> \n> This could even be extended to allow one to \"open file AAA for edit as \n> aAa.v2', giving the file an alternate name.\n> \n> Such a workflow would only need to be used for such files, and could \n> also be used when there are incompatible file names for that given \n> partition type.\n\nThe hard part is actually identifying what the user's filesystem has done. \nThere's pretty good internal support for git knowing that, for a \nparticular entry, the filesystem should not be consulted for information. \nI don't think anyone's come up with a suitably cross-platform and \nautomatic way to figure out what's happened when git tries to write to a \nparticular filename and the system decides it is the same as some other \nfilename or it decides to use a different filename instead.\n\nOf course, it is reasonably likely that a project whose files can't all be \nchecked out can't be dealt with anyway on that platform (IIRC, the Linux \nkernel build system assumes that it can create both .S and .s files, so it \nwon't build on FAT). So nobody's been sufficiently motivated to try to \nimplement a fix.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"101312","messageId":"1232486929.4179.7.camel@therock.nsw.bigpond.net.au","threadId":"16672","inReplyTo":"alpine.LNX.1.00.0901201441480.19665@iabervon.org","subject":"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]","fromName":"John Chapman","fromEmail":"thestar@fussycoder.id.au","sentAt":"2009-01-20T21:28:49Z","receivedAt":"2009-01-20T21:28:49Z","isPatch":false,"sender":{"key":"thestar@fussycoder.id.au","avatar":null},"body":"On Tue, 2009-01-20 at 15:11 -0500, Daniel Barkalow wrote:\n\n> \n> The hard part is actually identifying what the user's filesystem has done. \n> There's pretty good internal support for git knowing that, for a \n> particular entry, the filesystem should not be consulted for information. \n> I don't think anyone's come up with a suitably cross-platform and \n> automatic way to figure out what's happened when git tries to write to a \n> particular filename and the system decides it is the same as some other \n> filename or it decides to use a different filename instead.\n\nThis would only need to interact with the git status command, wouldn't\nit?\n\n> \n> Of course, it is reasonably likely that a project whose files can't all be \n> checked out can't be dealt with anyway on that platform (IIRC, the Linux \n> kernel build system assumes that it can create both .S and .s files, so it \n> won't build on FAT). So nobody's been sufficiently motivated to try to \n> implement a fix.\n\nI doubt the kernel builds on windows, but this would allow a windows\nuser to modify such files, perhaps in preparation for a patch that does\nallow the kernel to be built on windows?\n(Of course, we're using the kernel here as an example, right? Nobody\nwould be insane as to want to use windows for that!)\n\nSee, a very annoying thing about windows is that it is quite simple for\na team to commit two files that differ by case alone to a git\nrepository.\n\nWas just an idea, really.\n"},{"id":"101304","messageId":"alpine.LNX.1.00.0901201651050.19665@iabervon.org","threadId":"16672","inReplyTo":"1232486929.4179.7.camel@therock.nsw.bigpond.net.au","subject":"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]","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-01-20T22:08:21Z","receivedAt":"2009-01-20T22:08:21Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 21 Jan 2009, John Chapman wrote:\n\n> On Tue, 2009-01-20 at 15:11 -0500, Daniel Barkalow wrote:\n> \n> > \n> > The hard part is actually identifying what the user's filesystem has done. \n> > There's pretty good internal support for git knowing that, for a \n> > particular entry, the filesystem should not be consulted for information. \n> > I don't think anyone's come up with a suitably cross-platform and \n> > automatic way to figure out what's happened when git tries to write to a \n> > particular filename and the system decides it is the same as some other \n> > filename or it decides to use a different filename instead.\n> \n> This would only need to interact with the git status command, wouldn't\n> it?\n\nThe information is needed in a bunch of commands (diff and add, for \nexample), but I believe that's already taken care on. The problem is \ngetting it set automatically instead of having git not notice that the \nfilesystem isn't doing what it expects.\n\n> > Of course, it is reasonably likely that a project whose files can't all be \n> > checked out can't be dealt with anyway on that platform (IIRC, the Linux \n> > kernel build system assumes that it can create both .S and .s files, so it \n> > won't build on FAT). So nobody's been sufficiently motivated to try to \n> > implement a fix.\n> \n> I doubt the kernel builds on windows, but this would allow a windows\n> user to modify such files, perhaps in preparation for a patch that does\n> allow the kernel to be built on windows?\n> (Of course, we're using the kernel here as an example, right? Nobody\n> would be insane as to want to use windows for that!)\n> \n> See, a very annoying thing about windows is that it is quite simple for\n> a team to commit two files that differ by case alone to a git\n> repository.\n\nMy impression was that this didn't happen in practice, because teams\nwould tend to not have two people create the same file at the same time, \nbut with different cases, and people interacting with the same file at \ndifferent times would use whatever case it was introduced with.\n\nI think I'd only heard about problems for people who were using \nfilesystems with different properties than what the rest of the developers \non the project were using.\n\nBut I've only ever worked on projects that expect case-sensitivity, and \nmostly on projects that have a standard style that prevents duplication.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"101316","messageId":"81b0412b0901201525w22513418p57acc19457908a3@mail.gmail.com","threadId":"16672","inReplyTo":"alpine.LNX.1.00.0901201651050.19665@iabervon.org","subject":"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]","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-01-20T23:25:16Z","receivedAt":"2009-01-20T23:25:16Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"2009/1/20 Daniel Barkalow :\n> My impression was that this didn't happen in practice, because teams\n> would tend to not have two people create the same file at the same time,\n> but with different cases, and people interacting with the same file at\n> different times would use whatever case it was introduced with.\n\nIt will and does happen in practice (annoingly too often even). Not with Git\nyet (with Perforce), where people do \"branching\" by simply copying things\nin another directory (perforce world does not know real branches),\nrenaming files randomly, and putting the new directory back in the\nsystem (or maybe it is the strange tools here which do that - often\nit is the first character of a directory or file which gets down- or up-cased).\nAs Perforce itself is case sensitive (like Git), using of such branches\nis a nightmare: the files get overwritten in checkout order which is\nnot always sorted in predictable order. Combined with case-stupidity\nof the file system the working directories sometimes cause \"interesting\ntime\" for unlucky users.\nLuckily (sadly) it is all-opening-in-a-wall shop, so the problem with \"fanthom\"\nfiles is rare (it is hard to notice) for most. Which actually makes it more\nfrustrating when the real shit happens.\n\nAnd it will happen to Git as well, especially if development go crossplatform.\nIt is not that hard to accidentally rename a file on case-sensitive file system,\n\"git add *\" it and commit without thinking (that's how most of software\ndevelopment happens, come to think of it).\n"},{"id":"101319","messageId":"alpine.LNX.1.00.0901201833400.19665@iabervon.org","threadId":"16672","inReplyTo":"81b0412b0901201525w22513418p57acc19457908a3@mail.gmail.com","subject":"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]","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-01-21T00:03:10Z","receivedAt":"2009-01-21T00:03:10Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 21 Jan 2009, Alex Riesen wrote:\n\n> 2009/1/20 Daniel Barkalow :\n> > My impression was that this didn't happen in practice, because teams\n> > would tend to not have two people create the same file at the same time,\n> > but with different cases, and people interacting with the same file at\n> > different times would use whatever case it was introduced with.\n> \n> It will and does happen in practice (annoingly too often even). Not with Git\n> yet (with Perforce), where people do \"branching\" by simply copying things\n> in another directory (perforce world does not know real branches),\n> renaming files randomly, and putting the new directory back in the\n> system (or maybe it is the strange tools here which do that - often\n> it is the first character of a directory or file which gets down- or up-cased).\n\nHow does the resulting code work at all? With a case-sensitive filesystem, \nmost of the files you're using don't have the expected names any more, and \nmost systems will therefore not actually build or run.\n\nI have to assume it's your strange tools, because we never have this \nproblem at my work, where we also use Perforce. Perhaps it's that we \nalways use \"p4 integrate //some/project/version/... \n//some/other/project/version/...\" which inherently preserves the case of \nall of the filenames within the project.\n\n> As Perforce itself is case sensitive (like Git), using of such branches\n> is a nightmare: the files get overwritten in checkout order which is\n> not always sorted in predictable order. Combined with case-stupidity\n> of the file system the working directories sometimes cause \"interesting\n> time\" for unlucky users.\n> Luckily (sadly) it is all-opening-in-a-wall shop, so the problem with \"fanthom\"\n> files is rare (it is hard to notice) for most. Which actually makes it more\n> frustrating when the real shit happens.\n> \n> And it will happen to Git as well, especially if development go crossplatform.\n> It is not that hard to accidentally rename a file on case-sensitive file system,\n> \"git add *\" it and commit without thinking (that's how most of software\n> development happens, come to think of it).\n\nPeople can accidentally rename files? And still have things work when they \ndo it on a case-sensitive filesystem?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"101350","messageId":"81b0412b0901202325y7a468374i4b1b3da0c7bd48dc@mail.gmail.com","threadId":"16672","inReplyTo":"alpine.LNX.1.00.0901201833400.19665@iabervon.org","subject":"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]","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-01-21T07:25:00Z","receivedAt":"2009-01-21T07:25:00Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"2009/1/21 Daniel Barkalow :\n> On Wed, 21 Jan 2009, Alex Riesen wrote:\n>\n>> 2009/1/20 Daniel Barkalow :\n>> > My impression was that this didn't happen in practice, because teams\n>> > would tend to not have two people create the same file at the same time,\n>> > but with different cases, and people interacting with the same file at\n>> > different times would use whatever case it was introduced with.\n>>\n>> It will and does happen in practice (annoingly too often even). Not with Git\n>> yet (with Perforce), where people do \"branching\" by simply copying things\n>> in another directory (perforce world does not know real branches),\n>> renaming files randomly, and putting the new directory back in the\n>> system (or maybe it is the strange tools here which do that - often\n>> it is the first character of a directory or file which gets down- or up-cased).\n>\n> How does the resulting code work at all? ...\n\nSometimes it does not. Sometimes it does. Depends on that particular\ncheckout order perforce (or user?) selected to use this time.\n\n> ... With a case-sensitive filesystem,\n> most of the files you're using don't have the expected names any more, and\n> most systems will therefore not actually build or run.\n\nExcept that there is no case-sensitive file systems on development machines.\nSo a botched case wont be noticed by a standard build procedure unless\nthe content of the files causes an error.\n\n>> As Perforce itself is case sensitive (like Git), using of such branches\n>> is a nightmare: the files get overwritten in checkout order which is\n>> not always sorted in predictable order. Combined with case-stupidity\n>> of the file system the working directories sometimes cause \"interesting\n>> time\" for unlucky users.\n>> Luckily (sadly) it is all-opening-in-a-wall shop, so the problem with \"fanthom\"\n>> files is rare (it is hard to notice) for most. Which actually makes it more\n>> frustrating when the real shit happens.\n>>\n>> And it will happen to Git as well, especially if development go crossplatform.\n>> It is not that hard to accidentally rename a file on case-sensitive file system,\n>> \"git add *\" it and commit without thinking (that's how most of software\n>> development happens, come to think of it).\n>\n> People can accidentally rename files?\n\nAside from tools (and in my own experience - I did) - they can and do.\n\n> And still have things work when they do it on a case-sensitive filesystem?\n\nShameless luck, I'd say. That and \"no file systems permitted, but the one\nfrom finance dept\".\n"}]}