{"thread":{"id":"3207","subject":"Re: [Census] So who uses git?","startedAt":"2006-02-01T07:08:47Z","lastAt":"2006-02-01T21:27:35Z","messageCount":5,"participants":["linux@horizon.com","Junio C Hamano","Linus Torvalds","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15372","messageId":"20060201070847.2021.qmail@science.horizon.com","threadId":"3207","inReplyTo":null,"subject":"Re: [Census] So who uses git?","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2006-02-01T07:08:47Z","receivedAt":"2006-02-01T07:08:47Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> Yes, I think the \"assume unchanged\" flag goes well together with making \n> sure that the checked-out file is non-writable at the time.\n> \n> Of course, any number of editors and other actions won't care: if you do \n> anything like\n> \n> \tfor i in *.c\n> \tdo\n> \t\tsed 's/xyzzy/bas/g' < $i > $i.new\n> \t\tmv $i.new $i\n> \tdone\n> \n> you'll never have even noticed that the old file was marked read-only. So \n> it's obviously not in any way any guarantee, but it probably makes sense \n> as a crutch.\n\nAt the risk of complicating something already very complicated, and\npossibly breaking on Microsoft file systems, that case can be detected\nby reading the directory and noticing that the inode number changed.\n\nWould it be worth validating the inode numbers (which can be retrieved\nin a batch) even if you don't do a full lstat()?\n\nOr is that too Unix-centric and prone to performance problems on other\nfile systems? I'd think that, even if a file system used fake inode\nnumbers, they'd be pretty consistent if you didn't touch the file at all,\nand being different would just cause a more expensive validation.\nWhich would be okay as long as it's infrequent.\n"},{"id":"15379","messageId":"7vslr3ea1f.fsf@assigned-by-dhcp.cox.net","threadId":"3207","inReplyTo":"20060201070847.2021.qmail@science.horizon.com","subject":"Re: [Census] So who uses git?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-01T08:51:56Z","receivedAt":"2006-02-01T08:51:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"linux@horizon.com writes:\n\n> At the risk of complicating something already very complicated, and\n> possibly breaking on Microsoft file systems, that case can be detected\n> by reading the directory and noticing that the inode number changed.\n>\n> Would it be worth validating the inode numbers (which can be retrieved\n> in a batch) even if you don't do a full lstat()?\n\nI suspect that what you said about Microsoft filesystems is even\nstronger. IIRC the latest Cygwin stopped giving d_ino regardless\nof the filesystem type; you need to do a stat() anyway.\n"},{"id":"15405","messageId":"Pine.LNX.4.64.0602010800090.21884@g5.osdl.org","threadId":"3207","inReplyTo":"20060201070847.2021.qmail@science.horizon.com","subject":"Re: [Census] So who uses git?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-01T16:04:18Z","receivedAt":"2006-02-01T16:04:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 1 Feb 2006, linux@horizon.com wrote:\n> \n> At the risk of complicating something already very complicated, and\n> possibly breaking on Microsoft file systems, that case can be detected\n> by reading the directory and noticing that the inode number changed.\n> \n> Would it be worth validating the inode numbers (which can be retrieved\n> in a batch) even if you don't do a full lstat()?\n\nI don't think it's worth it. It's the unusual case anyway, and it doesn't \neven really guarantee anything either (the person _could_ just have marked \nthe inode writable - not understanding what is going on, he could have \njust done a \"chmod +w\" behind git's back).\n\nTogether with the fact that it might not work everywhere, and that I could \nwell imagine that \"readdir()\" is slow on cygwin too (how does it do \n\"d_ino\"? Maybe it has to do a stat() to emulate unix behaviour?), I'm not \nconvinced it's worth it.\n\nI think the whole \"assume it's valid\" is a crutch - but if we do it, we \nshould make it _really_ fast, because it's also useful for automated \nprocedures that _know_ which files they touch. So we should make it have \nminimal impact.\n\n\t\tLinus\n"},{"id":"15406","messageId":"81b0412b0602010810m3577263csed57ba75e0d6bb64@mail.gmail.com","threadId":"3207","inReplyTo":"20060201070847.2021.qmail@science.horizon.com","subject":"Re: [Census] So who uses git?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-02-01T16:10:48Z","receivedAt":"2006-02-01T16:10:48Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1 Feb 2006 02:08:47 -0500, linux@horizon.com wrote:\n> > Yes, I think the \"assume unchanged\" flag goes well together with making\n> > sure that the checked-out file is non-writable at the time.\n> >\n> > Of course, any number of editors and other actions won't care: if you do\n> > anything like\n> >\n> > for i in *.c\n> > do\n> > sed 's/xyzzy/bas/g' < $i > $i.new\n> > mv $i.new $i\n> > done\n> >\n> > you'll never have even noticed that the old file was marked read-only. So\n> > it's obviously not in any way any guarantee, but it probably makes sense\n> > as a crutch.\n>\n> At the risk of complicating something already very complicated, and\n> possibly breaking on Microsoft file systems, that case can be detected\n> by reading the directory and noticing that the inode number changed.\n\nInodes are either uselessor dangerous in cygwin (hash of an\nabsolute pathname on FAT). They may not even change after rm+touch.\n"},{"id":"15431","messageId":"20060201212735.18283.qmail@science.horizon.com","threadId":"3207","inReplyTo":"81b0412b0602010810m3577263csed57ba75e0d6bb64@mail.gmail.com","subject":"Re: [Census] So who uses git?","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2006-02-01T21:27:35Z","receivedAt":"2006-02-01T21:27:35Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> Inodes are either uselessor dangerous in cygwin (hash of an\n> absolute pathname on FAT). They may not even change after rm+touch.\n\nYes, I just looked it up and found that out. I was hoping they used\nfirst block number like many Linux FSes have tried, in which case it\nwould have worked, but if it's a hash of the path name, it's\nguaranteed not to change.\n\nAnd Linus' point is excellent, too: this feature is also useful\nfor automated systems (like git-applypatch) that can be assumed to\nnever forget to warn git ahead of time.\n"}]}