On Sun, Sep 16, 2007 at 08:08:59AM +0200, martin f krafft wrote:
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.
I haven't followed the discussion at all I must admit (I wrote metastore
as a quick hack to store some extended metadata and it works for my
purposes as long as I don't do anything fancy). But I agree, if any
changes were made to git, I'd advocate adding arbitrary attributes to
files (much like xattrs) in name=value pairs, then any extended metadata
could be stored in those attributes and external scripts/tools could use
them in some way that makes sense...and also make sure to only update
them when it makes sense.
--
David Härdeman
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
