Re: confused about preserved permissions
- From
David Kastrup <dak@gnu.org>
- Date
- Aug 20, 2007, 17:58 UTC
- Message-ID
- <867inqhyuk.fsf@lola.quinscape.zz>
- In-Reply-To
- <20070820174142.GA7943@glandium.org>
Mike Hommey <mh@glandium.org> writes:
Show 8 quoted lines
> On Mon, Aug 20, 2007 at 06:44:11PM +0200, martin f krafft <madduck@madduck.net> wrote: >> Why does git bother saving a mode when later it never seems to use >> it again? > > Same applies to git-archive, which generates files with mode 666 and > directories with 777, while it could follow the modes in the > repository... or at least, that's what the manpage claims, but facts > seem to be quite different...
Git had permissions at one point of time. It makes colloboration with other people with different umasks a nuisance. However, not all uses are colloborative. So it might be nice to be able to specify permission/uid/gid policies that do a configurable level of munging for stuff passed into and out of the index and/or the repositories.
> I also never understood why there were no permissions set on > directories in trees...
Because directories are not actually tracked. They are created and deleted as-needed.
In my proposal for allowing directories to get tracked, permissions of 000 would indicate a tree without a corresponding tracked directory. Other permissions would correspond to a tracked directory. I am still stuck over the representation in the index.
One idea is to unconditionally have an entry "dirname" without permissions, and optionally "dirname/" with permissions iff the directory is supposed to be tracked, both to be sorted in alphabetically. The idea of the first entry is being able to detect merge conflicts without extra passes.
But I have not worked on the stuff for a while.
> nor why, while the sha1 for child objects are "packed", the modes > aren't...
Because a change of the mode of a file will then not cause different sha1 sums at the file level.
-- David Kastrup