"Josh England" <jjengla@sandia.gov> writes:

quoted text
> But the stat data (even uid/gid) is in there nonetheless, right?  If
> everything is in there already I wouldn't need to add a thing.  I just
> want to access the index cache rather than hitting the filesystem
> directly.

But to use that data you would need extra code to move things
from there to gitattributes, wouldn't you?  I can see that you
could "stage" change of ownership in the index and attempt to
commit by nonexisting

	git update-index --chown root foo.c

which would say "foo.c is now owned by uid #0", but before the
next git-commit-tree runs, somebody (namely, "git-commit") has
to run a possibly enhanced "git diff-files" (traditionally
uid/gid are NOT part of contents at all, so diff-files would not
say ownership has changed between the filesystem and index in
what way at all) to notice that ownership has changed, and
update .gitattributes.

Then you need to also "git update-index" the .gitattributes as
well, to record the ownership change in the commit.  What if the
user had unrelated changes that the user does not want to commit
in .gitattributes?

It will quickly become a mess.

It would rather be more effective for the user action "I want to
change the ownership of foo.c to root" to cause a direct
manipulation of .gitattributes file.  For this, we can add a
nice wrapper if there is a need, but the initial cut could be
just running "${EDITOR-${VISUAL-vi}} .gitattributes", nothing
more.

The user can say "git diff" to view .gitattributes changes, and
if that is what he wants (maybe he wants to do "git add -i" to
pick only the hunk about the ownership change for the next
commit), the change to .gitattributes can be committed.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html