On Sun, Sep 16, 2007 at 08:14:11 +0200, martin f krafft wrote: > also sprach Johannes Schindelin <Johannes.Schindelin@xxxxxx> [2007.09.16.0014 +0200]: > > 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. > > Like rsync, git would use numerical UIDs (which are always present) > by default, but could be told to try to map account names. > > If the filesystem does not support owners, chown() would not exist. > I actually tend to think of things the other way around: instead of > a fallback when chown() does not work (what would such a fallback be > other than not chown()ing?), it would only try chown() if such > functionality existed. There's a problem. You need to know that the functionality is missing and not try to read attributes back, but instead consider them unchanged. Nothing that can't be taken care of, but it needs to be handled carefuly. > > And a fallback when a non-root user uses it. > > That's easy, Unix already provides you with that "fallback": pack up > /etc in a tar and unpack it as a normal user... But if you tar that up again, the owners will be different. But you don't want the change. > > 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. > > Provided we find a way to implement this in an extensible manner, > this should not be hard to do. I can't do it since I don't have > access to a Windows machine. > > Your statement does catch me off-guard though. Does git now > officially target Windows? Official git works in cygwin. There is also a port to msys, which is not official in a sense it is not merged into mainline. -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
