On Sat, 16 Apr 2005, Paul Jackson wrote:
>
> Morten wrote:
> > It makes some sense in principle, but without storing what they mean
> > (i.e., group==?) it certainly makes no sense.
>
> There's no "they" there.
>
> I think Martin's proposal, to which I agreed, was to store a _single_
> bit. If any of the execute permissions of the incoming file are set,
> then the bit is stored ON, else it is stored OFF. On 'checkout', if the
> bit is ON, then the file permission is set mode 0777 (modulo umask),
> else it is set mode 0666 (modulo umask).
I think I agree.
Anybody willing to send me a patch? One issue is that if done the obvious
way it's an incompatible change, and old tree objects won't be valid any
more. It might be ok to just change the "compare cache" check to only care
about a few bits, though: S_IXUSR and S_IFDIR. And then always write new
"tree" objects out with mode set to one of
- 040000: we already do this for directories
- 100644: normal files without S_IXUSR set
- 100755: normal files _with_ S_IXUSR set
Then, at compare time, we only look at S_IXUSR matching for files (we
never compare directory modes anyway). And at file create time, we create
them with 0666 and 0777 respectively, and let the users umask sort it out
(and if the user has 0100 set in his umask, he can damn well blame
himself).
This would pretty much match the existing kernel tree, for example. We'd
end up with some new trees there (and in git), but not a lot of
incompatibility. And old trees would still work fine, they'd just get
written out differently.
Anybody want to send a patch to do this?
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
