On Sat, 15 Sep 2007, Daniel Barkalow wrote:
The reason why I say this should be done inside git rather than with
hooks and an external tool, such as metastore is quite simple: git
knows about every content entity in any tree of a repo and already has
a data node for each object. Rather than introducing a parallel object
database (shadow hierarchy or single file), it would make a lot more
sense and be way more robust to attach additional information to these
object nodes, wouldn't it?
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. 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)
don't underestimate the usefullness of the ability to archive and restore
snapshots of a live system. just that ability would be wonderful to have.
the ability to checkout a copy of things elsewhere and tinker with it
would be better, but the lack of that doesn't eliminate the utility by any
means.
David Lang
, the normal case will be that
the metadata beyond +x is manipulated by ordinary users in some way
other than modifying their working directory. 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.
-
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
