Rafal Rusin <rafal.rusin@xxxxxxxxx> writes:
> I'm hosting git repository on filesystem with 'chmod <some-file>'
> causing permission denied error (it's smbfs mounted directory),
> When I was doing push to such repo using file:// protocol, I got
> following error:
> error: unable to set permission to './objects/...'
>
> I did a small fix to sha1_file.c (patch in attachment) and git now
> warns when unable to chmod, and continues push. This resolved problem.
> What do you think about applying it?
Suppose the user wanted to use this as a shared public repository and
configured core.sharedrepository. If we try to set shared-perm and notice
a failure but keep going, what happens to the resulting repository?
For example, the umask of the user who is pushing objects, causing this
codepath to run, might be too tight to be usable for the purpose of making
the file readable for other members of the group. And the chmod() fails
in this codepath. Then what? Wouldn't it make the resulting repository
unusable?
I think a _fix_ needs to first know why chmod is failing for you and
either
(1) make it not to fail; or
(2) Perhaps your filesystem is lying and the result of chmod happens to
be Ok (iow, the resulting file may be readable/writable by people who
are supposed to be able to, accoring to the core.sharedrepository
settings), in which case make the code notice the situation and keep
going _only when_ it is safe to do so.
I do not think your change to _unconditionally_ keep going is a fix.
--
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