also sprach Jan Hudec <bulb@xxxxxx> [2007.09.16.1751 +0200]: > > 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. This is a good consideration. One way of implementing this seems to be to iterate over all file attributes recorded in the object cache (or metastore) and try to apply each. For every attribute that was properly applied to the worktree, a note is attached to the object's data in the index. Tools identifying differences between index and worktree would then only pay attention to these attributes. > But if you tar that up again, the owners will be different. But > you don't want the change. As per my above suggestion, this would solve itself. Untarring as non-root simply means that the chmod/chown/whatever calls would fail or not be tried at all. Thus, they would not be recorded in the index and later commits would never consider changes to these attributes. One could probably simplify the implementation such that failure to chmod/chown/whatever a single file would make the attribute be ignored when worktree and index are compared. Then, it would all boil down to a combination of configuration and functionality: the attributes the user wants to have tracked (configuration) and those which can be applied to the worktree when logically and'ed result in the final mask of attributes to consider when identifying changes. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck a gourmet concerned about calories is like a punter eyeing the clock. spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
