{"thread":{"id":"6801","subject":"git-cvsserver doesn't respect core.sharedrepository","startedAt":"2007-02-13T14:38:27Z","lastAt":"2007-03-05T05:15:43Z","messageCount":7,"participants":["Andy Parkins","Johannes Schindelin","Nicolas Pitre","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"34410","messageId":"200702131438.30291.andyparkins@gmail.com","threadId":"6801","inReplyTo":null,"subject":"git-cvsserver doesn't respect core.sharedrepository","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-13T14:38:27Z","receivedAt":"2007-02-13T14:38:27Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Hello,\n\nI'm using git-cvsserver with a repository that has core.sharedrepository set \nto \"group\". After a commit has been pushed using git-cvsserver I have to \ncorrect the permissions again.\n\nI suspect then that git-cvsserver is somehow bypassing git's normal fixing of \nthe permissions bits. I'm not entirely sure though, as I can't entirely see \nhow the calling of path.c:adjust_shared_perm() can be avoided.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"34412","messageId":"Pine.LNX.4.63.0702131611010.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6801","inReplyTo":"200702131438.30291.andyparkins@gmail.com","subject":"Re: git-cvsserver doesn't respect core.sharedrepository","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-13T15:11:58Z","receivedAt":"2007-02-13T15:11:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 13 Feb 2007, Andy Parkins wrote:\n\n> I'm using git-cvsserver with a repository that has core.sharedrepository set \n> to \"group\". After a commit has been pushed using git-cvsserver I have to \n> correct the permissions again.\n\nAre you sure?\n\nSince ref updates are not write-into-existing-file, but rather \nwrite-into-new-file-and-replace-old, it should work, no?\n\nCiao,\nDscho\n"},{"id":"34419","messageId":"200702131605.29088.andyparkins@gmail.com","threadId":"6801","inReplyTo":"Pine.LNX.4.63.0702131611010.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git-cvsserver doesn't respect core.sharedrepository","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-13T16:05:27Z","receivedAt":"2007-02-13T16:05:27Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 February 13 15:11, Johannes Schindelin wrote:\n\n> Since ref updates are not write-into-existing-file, but rather\n> write-into-new-file-and-replace-old, it should work, no?\n\nThat perhaps might be the explanation for the bad behaviour. The ref is being \nupdated in git-cvsserver by writing the new head hash into the lockfile then \ndoing\n\n unlink($reffile);\n rename($lockfile, $reffile);\n\nThe lockfile is made with whatever umask is in place, so the \nsharedrepository=group is being ignored. The solution then is to use the \npermissions of the existing reffile when creating the lockfile.\n\nThanks Johannes. One little sentence and it all becomes clear :-)\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"34422","messageId":"Pine.LNX.4.64.0702131139490.1757@xanadu.home","threadId":"6801","inReplyTo":"200702131605.29088.andyparkins@gmail.com","subject":"Re: git-cvsserver doesn't respect core.sharedrepository","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-13T16:48:53Z","receivedAt":"2007-02-13T16:48:53Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 13 Feb 2007, Andy Parkins wrote:\n\n> That perhaps might be the explanation for the bad behaviour. The ref is being \n> updated in git-cvsserver by writing the new head hash into the lockfile then \n> doing\n> \n> unlink($reffile);\n> rename($lockfile, $reffile);\n\nWouldn't it be much better if it used git-update-ref instead? This \nmanual ref updating looks like it has a potential for races to me.\n\nAlso git-update-ref should probably be used with -m to create reflog \nentries.\n\n\nNicolas\n"},{"id":"34449","messageId":"Pine.LNX.4.63.0702131910020.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6801","inReplyTo":"200702131605.29088.andyparkins@gmail.com","subject":"Re: git-cvsserver doesn't respect core.sharedrepository","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-13T18:10:51Z","receivedAt":"2007-02-13T18:10:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 13 Feb 2007, Andy Parkins wrote:\n\n> On Tuesday 2007 February 13 15:11, Johannes Schindelin wrote:\n> \n> > Since ref updates are not write-into-existing-file, but rather\n> > write-into-new-file-and-replace-old, it should work, no?\n> \n> That perhaps might be the explanation for the bad behaviour.\n\nUmmm. What I tried to say is that this is intended behaviour, not bad \nbehaviour. The file does not have to have write permissions for the group. \nThe _directory_ has to have them.\n\nCiao,\nDscho\n"},{"id":"34455","messageId":"200702131821.37284.andyparkins@gmail.com","threadId":"6801","inReplyTo":"Pine.LNX.4.63.0702131910020.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git-cvsserver doesn't respect core.sharedrepository","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-13T18:21:34Z","receivedAt":"2007-02-13T18:21:34Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007, February 13, Johannes Schindelin wrote:\n\n> Ummm. What I tried to say is that this is intended behaviour, not bad\n> behaviour. The file does not have to have write permissions for the\n> group. The _directory_ has to have them.\n\nIt's not just write permissions. The default umask could also prevent \nread access by the group - the new ref needs to be readable by the \ngroup.\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\nandyparkins@gmail.com\n"},{"id":"36280","messageId":"46a038f90703042115r3ce1498cmdddc0dc11c9d4b2a@mail.gmail.com","threadId":"6801","inReplyTo":"200702131821.37284.andyparkins@gmail.com","subject":"Re: git-cvsserver doesn't respect core.sharedrepository","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-03-05T05:15:43Z","receivedAt":"2007-03-05T05:15:43Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 2/14/07, Andy Parkins wrote:\n> On Tuesday 2007, February 13, Johannes Schindelin wrote:\n>\n> > Ummm. What I tried to say is that this is intended behaviour, not bad\n> > behaviour. The file does not have to have write permissions for the\n> > group. The _directory_ has to have them.\n>\n> It's not just write permissions. The default umask could also prevent\n> read access by the group - the new ref needs to be readable by the\n> group.\n\nI agree. cvsserver depends on the user's umask just like an oldstyle\ncvs server. This is probably wrong, and you are right - we should\nrespect core.sharedrepository.\n\nThe recent change to use git-update-ref should have fixed part of the\nproblem. The other part of the problem is the handling of the sqlite\nfiles. All the other operations that leave permanent files in the repo\nare using git plumbing so we are safe.\n\nTo fix the sqlite files handling, the fix is to change the umask early\non if core.sharedrepository is true.\n\ncheers,\n\n\nmartin\n"}]}