2009/11/23 Junio C Hamano <gitster@xxxxxxxxx>: > 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. Thanks for reply. You are right about sharedrepository argument. As for detecting this particular case, I think it's not possible. I think the best solution is to add repository config switch like 'usefilepermissions' true by default. If set to false, git would skip chmod during push. Does that make sense to you? Regards, -- Rafał Rusin http://rrusin.blogspot.com http://www.touk.pl http://top.touk.pl -- 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