Benoit SIGOURE <tsuna@xxxxxxxxxxxxx> writes: > Someone on IRC pointed me to http://git.or.cz/gitwiki/ > ContentLimitations which says: > > "By design, git cannot track other aspects of the filesystem, including: > * File modes (except for the "executable" bit, and being symbolic > link)" > > That's weird since the file mode is saved in the tree, isn't there a > way to ask Git to restore this file mode? The wording you quoted is wrong. By design, we "chose not to" track other aspects, even though the underlying data structure has enough space to use other bit patterns. We deliberately chose not to use that space, and this default is very unlikely to change. In very early days of git, we allowed the work tree modes 0644 vs 0664 propagated back to the index modes and regular file modes recorded in the tree entries. This caused unnecessary pain for poeple merging real projects for no real gain whatsoever, and the behaviour was fixed to minimally track, hence we do not track anything but executable bits. I do not oppose to a new per-project configuration option to make use of the existing space to record differences vs 0644 vs 0664 vs 0600. However, I have already seen the downsides, so: (1) I am not interested in implementing that myself; (2) the places that canonicalize the mode bits obtained from the filesystem to 0644 is fairly centralized so it would not be too hard to implement (and that is one good reason why I do _not_ have to be the person to do so); (3) however, (2) means that everybody calls that canonicalization logic, and the unintended side effects need to be audited for codepaths of all the callers, which means a large test suite is probably needed; and (4) to me, reviewing such a patch will be much lower priority than other patches for the above reasons. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
