also sprach Daniel Barkalow <barkalow@xxxxxxxxxxxx> [2007.09.15.2156 +0200]: > Configuration options only apply to the local aspects of the repository. > That is, when you clone a repository, you don't get the configuration > options from it, in general. And changing configuration options on a > repository does not have any effect on the content it contains. So > configuration options aren't appropriate. Sure they are. Just like git-commit figures out your email address if user.email is missing from git-config, or core.sharedRepository or core.umask deal with permissions only when you tell them to, you'd have to enable core.track or else git would just do what it does right now. > Git doesn't have any way to represent owners or groups, and they > would need to be represented carefully in order to make sense > across multiple computers. If you're adding support for > metadata-as-content (for more than "is this a script?"), you > should be able to cover all of the common cases of extended stuff, > like AFS-style ACLs. Ideally, git should be able to store an open-ended number of properties for each object, yes. > And if you want to allow meaningful development with this > mechanism (as opposed to just archival of a sequence of states of > a live system), the normal case will be that the metadata beyond > +x is manipulated by ordinary users in some way other than > modifying their working directory. I have no idea what you mean with that. > So the normal case here will be like working on a filesystem that > doesn't support symlinks or an executable bit when this is > important content. ... and yet, we support symlinks and executable files. But anyway, I really don't understand what you're trying to say. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck "ist gott eine erfindung des teufels?" - friedrich nietzsche spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
