Re: tracking perms/ownership

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 24, 2007, 20:37 UTC
Message-ID: <7vfy28d5yl.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1187981803.6357.173.camel@beauty>

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

> 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.