Re: tracking perms/ownership
- From
David Kastrup <dak@gnu.org>
- Date
- Aug 24, 2007, 21:30 UTC
- Message-ID
- <85wsvkfwnc.fsf@lola.goethe.zz>
- In-Reply-To
- <alpine.LFD.0.999.0708241039250.25853@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 8 quoted lines
> On Fri, 24 Aug 2007, David Kastrup wrote: > >> In your example, neither installed files nor ownership are tracked >> in the filesystem. Both are "tracked" in the Makefile. Or rather >> than being tracked, they are explicitly catered for by the user. > > And I seriously am saying that that is the only way to handle things > sanely in a distributed content tracker like git.
Well, maybe _if_ you are using it as a distributed content tracker. But git is excellent at tracking contents (and resolving conflicts and merged) even if you _don't_ distribute.
Anyway, my beef with using something like .gitattributes or similar for tracking permissions is twofold:
a) if I am tracking a directory, having to track additional files clutters the directory. So if one uses a separate file for tracking, it should be able to use a file that is not actually in the work tree. But it still needs to be versioned. One could possibly fudge this by creating an artificial work tree with the tracked directory being in a subdirectory of it, but that's all pretty dorky.
b) merge resolution and movement tracking. Delegating stuff to a file and using the _file_ merging and tracking mechanisms is just not really the same thing. So it would be nice to at least have "pluggable merge strategies" for particular files, or treat gitattributes special with regard to merging, anyway.
Personally, I'm leaning towards a pluggable policy system containing rules how permission information is represented textually in the repository (that would allow acls and uid gid information), how the index is updated from repo and workdir and vice versa. The default policy would just talk about 777 or 666 (or 775 and 644) as it does now.
We already have a policy flag that optionally blocks the information flow from/to the index regarding executable bits. So it is not like the concept is alien.
On the matter of taste: I feel fine about storing numerical uid/gid data in the index, but I am already getting queasy with the idea of storing them numerically in the repository: that's a place where I find symbolic names more appropriate.
-- David Kastrup, Kriemhildstr. 15, 44793 Bochum