Re: tracking perms/ownership [was: empty directories]
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Aug 25, 2007, 14:31 UTC
- Message-ID
- <Pine.LNX.4.64.0708251630460.16728@wbgn129.biozentrum.uni-wuerzburg.de>
- In-Reply-To
- <20070824205820.GA19152@coredump.intra.peff.net>
Hi,
On Fri, 24 Aug 2007, Jeff King wrote:
Show 20 quoted lines
> On Fri, Aug 24, 2007 at 09:50:32AM -0600, Josh England wrote: > > > > direction and not at least consider people storing actual ACLs (or even > > > other extended attributes). An already-standard format like that > > > > Do you mean using acls through contrib/hooks/update-paranoid? That is > > the only place I see any mention of them. clean and smudge seem out > > because they are passed blob objects and have no notion of pathname. I > > don't see how to use this for automatic storing/restoring of > > perms/ownership. > > No, I mean filesystem ACLs. Your complaint is that git stores only the > file _content_, not some specific metadata that you want (owner, group, > permissions). My point is that there is _other_ metadata, too (such as > POSIX ACLs) that could be stored. Even if you don't want to store them, > if you are extending git's capabilities, it makes sense to at least > consider how to handle those cases, too. > > But yes, clean and smudge don't get the pathname. It would be a fairly > trivial patch, though, so maybe I'll play with it.
Yes, please do. Even if you do not end up implementing the perms/owner tracking using the clean/smudge filter, it seems odd that the filter should not get the filename.
Ciao, Dscho