On Sat, 15 Sep 2007, Johannes Schindelin wrote:
On Sat, 15 Sep 2007, Daniel Barkalow wrote:
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.
[speaking mostly to the proponents of git-as-a-backup-tool]
While at it, you should invent a fallback what to do when the owner is not
present on the system you check out on. And a fallback when checking out
on a filesystem that does not support owners.
And a fallback when a non-root user uses it.
Oh, and while you're at it (you said that it would be nice not to restrict
git in any way: "it is a content tracker") support the Windows style
"Group-or-User-or-something:[FRW]" ACLs.
git has pre-commit hooks that could be used to gather the permission
information and store it into a file.
git now has the ability to define cusom merge strategies for specific file
types, which could be used to handle merges for the permission files.
what git lacks the ability to do is to deal with special cases on
checkout.
the handling of gitattributes came really close, but there are two
problems remaining.
1. whatever is trying to write the files with the correct permissions
needs to be able to query the permission store before files are
written. This needs to either be an API call into git to retreive the
information for any file when it's written, or the ability to define a
specific file to be checked out first so that it can be used for
everything else.
2. the ability to specify a custom routine/program to write the file out
(assuming that it's being written to a filesystem not a pipe). this
routine would be responsible for querying the permission store and
doing 'the right thing' when the file is written during a checkout
there are some significant advantages of having the permission store be
just a text file.
1. it doesn't require a special API to a new datastore in git
2. when working in an environment that doesn't allow for implementing the
permissions (either a filesystem that can't store the permissions or
when not working as root so that you can't set the ownership) the file
can just be written and then edited with normal tools.
3. normal merge tools do a reasonable job of merging them.
however to do this git would need to gain the ability to say 'this
filename is special, it must be checked out before any other file is
checked out' (either on a per-directory or per-repository level)
if this is acceptable then altering the routines that write the files to
have the additional option of calling a different routine based on the
settings in .gitattributes seems relativly simple. there should already be
logic to decect if it's writing to a pipe or a filesystem (it needs to
know if it should set the write bit if nothing else), and there's the
existing passthrough or custom routine logic for the crlf translation from
.gitattributes. combining the logic of the two should handle the output
issues.
the ability to handle /etc comes up every few months. it's got to be the
most common unimplemented request git has seen. Adding the nessasary hooks
for it to be done could end up being less effort then repeatedly telling
people that they shouldn't use git for that task (or should wrap git in
their own scripts and use the result instead of useing git directly)
so would changes like this be acceptable?
David Lang
-
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
