On Sun, Sep 16, 2007 at 08:14:11 +0200, martin f krafft wrote:
quoted text
> also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.09.16.=
0014 +0200]:
quoted text
> > 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.
>=20
> Like rsync, git would use numerical UIDs (which are always present)
> by default, but could be told to try to map account names.
>=20
> 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 n=
ot
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.

quoted text
> > And a fallback when a non-root user uses it.
>=20
> 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.

quoted text
> > 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.
>=20
> 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.
>=20
> 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.

--=20
						 Jan 'Bulb' Hudec <bulb@ucw.cz>