threads / discuss / 3207

Re: [Census] So who uses git?

Subject: Re: [Census] So who uses git?

## tl;dr

5 messages between Feb 1, 2006 and Feb 1, 2006.

replies: 4people: 4as markdown or json

linux@horizon.com· Feb 1, 2006, 07:08 UTC · lore
Show 15 quoted lines
> Yes, I think the "assume unchanged" flag goes well together with making 
> sure that the checked-out file is non-writable at the time.
> 
> Of course, any number of editors and other actions won't care: if you do 
> anything like
> 
> 	for i in *.c
> 	do
> 		sed 's/xyzzy/bas/g' < $i > $i.new
> 		mv $i.new $i
> 	done
> 
> you'll never have even noticed that the old file was marked read-only. So 
> it's obviously not in any way any guarantee, but it probably makes sense 
> as a crutch.

At the risk of complicating something already very complicated, and possibly breaking on Microsoft file systems, that case can be detected by reading the directory and noticing that the inode number changed.

Would it be worth validating the inode numbers (which can be retrieved in a batch) even if you don't do a full lstat()?

Or is that too Unix-centric and prone to performance problems on other file systems? I'd think that, even if a file system used fake inode numbers, they'd be pretty consistent if you didn't touch the file at all, and being different would just cause a more expensive validation. Which would be okay as long as it's infrequent.

Junio C Hamano· Feb 1, 2006, 08:51 UTC · re: linux@horizon.com · lore
linux@horizon.com writes:
Show 6 quoted lines
> At the risk of complicating something already very complicated, and
> possibly breaking on Microsoft file systems, that case can be detected
> by reading the directory and noticing that the inode number changed.
>
> Would it be worth validating the inode numbers (which can be retrieved
> in a batch) even if you don't do a full lstat()?

I suspect that what you said about Microsoft filesystems is even stronger. IIRC the latest Cygwin stopped giving d_ino regardless of the filesystem type; you need to do a stat() anyway.

Linus Torvalds· Feb 1, 2006, 16:04 UTC · re: linux@horizon.com · lore
On Tue, 1 Feb 2006, linux@horizon.com wrote:
Show 7 quoted lines
> 
> At the risk of complicating something already very complicated, and
> possibly breaking on Microsoft file systems, that case can be detected
> by reading the directory and noticing that the inode number changed.
> 
> Would it be worth validating the inode numbers (which can be retrieved
> in a batch) even if you don't do a full lstat()?

I don't think it's worth it. It's the unusual case anyway, and it doesn't even really guarantee anything either (the person _could_ just have marked the inode writable - not understanding what is going on, he could have just done a "chmod +w" behind git's back).

Together with the fact that it might not work everywhere, and that I could well imagine that "readdir()" is slow on cygwin too (how does it do "d_ino"? Maybe it has to do a stat() to emulate unix behaviour?), I'm not convinced it's worth it.

I think the whole "assume it's valid" is a crutch - but if we do it, we should make it _really_ fast, because it's also useful for automated procedures that _know_ which files they touch. So we should make it have minimal impact.

		Linus
Alex Riesen· Feb 1, 2006, 16:10 UTC · re: linux@horizon.com · lore
On 1 Feb 2006 02:08:47 -0500, linux@horizon.com <linux@horizon.com> wrote:
Show 19 quoted lines
> > Yes, I think the "assume unchanged" flag goes well together with making
> > sure that the checked-out file is non-writable at the time.
> >
> > Of course, any number of editors and other actions won't care: if you do
> > anything like
> >
> >       for i in *.c
> >       do
> >               sed 's/xyzzy/bas/g' < $i > $i.new
> >               mv $i.new $i
> >       done
> >
> > you'll never have even noticed that the old file was marked read-only. So
> > it's obviously not in any way any guarantee, but it probably makes sense
> > as a crutch.
>
> At the risk of complicating something already very complicated, and
> possibly breaking on Microsoft file systems, that case can be detected
> by reading the directory and noticing that the inode number changed.

Inodes are either uselessor dangerous in cygwin (hash of an absolute pathname on FAT). They may not even change after rm+touch.

linux@horizon.com· Feb 1, 2006, 21:27 UTC · re: Alex Riesen · lore
> Inodes are either uselessor dangerous  in cygwin (hash of an
> absolute pathname on FAT). They may not even change after rm+touch.

Yes, I just looked it up and found that out. I was hoping they used first block number like many Linux FSes have tried, in which case it would have worked, but if it's a hash of the path name, it's guaranteed not to change.

And Linus' point is excellent, too: this feature is also useful for automated systems (like git-applypatch) that can be assumed to never forget to warn git ahead of time.

← back to recent threads