{"thread":{"id":"23487","subject":"preventing destructive operations to central repository","startedAt":"2010-04-16T00:39:42Z","lastAt":"2010-04-16T01:03:44Z","messageCount":3,"participants":["Brendan Miller","Jay Soffian","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"139642","messageId":"j2yef38762f1004151739x497106eeo190b97f3eecc153f@mail.gmail.com","threadId":"23487","inReplyTo":null,"subject":"preventing destructive operations to central repository","fromName":"Brendan Miller","fromEmail":"catphive@catphive.net","sentAt":"2010-04-16T00:39:42Z","receivedAt":"2010-04-16T00:39:42Z","isPatch":false,"sender":{"key":"catphive@catphive.net","avatar":"https://gravatar.com/avatar/d6048400272e913886f5ee25c1bca2020dc014547231c1dc148fdfa1631e31d3?d=mp&s=160"},"body":"Let's say you have a bare git repository writeable by a number of\ndifferent people. How do you prevent them from borking the central\nrepository?\n\nAlso, is there an automated mechanism to ensure that the timeline\nstays clean? Say, force people to rebase their repositories before\nmerging into the shared repository?\n\nThanks\n"},{"id":"139644","messageId":"t2q76718491004151758p8862970bua5e7d60ccda8cdae@mail.gmail.com","threadId":"23487","inReplyTo":"j2yef38762f1004151739x497106eeo190b97f3eecc153f@mail.gmail.com","subject":"Re: preventing destructive operations to central repository","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-04-16T00:58:15Z","receivedAt":"2010-04-16T00:58:15Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Apr 15, 2010 at 8:39 PM, Brendan Miller <catphive@catphive.net> wrote:\n> Let's say you have a bare git repository writeable by a number of\n> different people. How do you prevent them from borking the central\n> repository?\n\nDepends what you mean by borking, but you might consider starting with\nreading the \"git config\" man page for the following entries:\n\n- receive.denyDeletes\n- receive.denyNonFastForwards\n\n> Also, is there an automated mechanism to ensure that the timeline\n> stays clean? Say, force people to rebase their repositories before\n> merging into the shared repository?\n\nIn order to prevent merges, you will need to use a a receive-pack hook such as:\n\nhttp://lists.gnu.org/archive/html/bug-gnulib/2008-10/msg00221.html\n\nYou might also consider something like gitosis/gitolite/gerrit\ndepending upon how formal you want to be.\n\nj.\n"},{"id":"139645","messageId":"20100416010344.GB6181@spearce.org","threadId":"23487","inReplyTo":"t2q76718491004151758p8862970bua5e7d60ccda8cdae@mail.gmail.com","subject":"Re: preventing destructive operations to central repository","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-04-16T01:03:44Z","receivedAt":"2010-04-16T01:03:44Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jay Soffian <jaysoffian@gmail.com> wrote:\n> On Thu, Apr 15, 2010 at 8:39 PM, Brendan Miller <catphive@catphive.net> wrote:\n> > Let's say you have a bare git repository writeable by a number of\n> > different people. How do you prevent them from borking the central\n> > repository?\n> \n> Depends what you mean by borking, but you might consider starting with\n> reading the \"git config\" man page for the following entries:\n> \n> - receive.denyDeletes\n> - receive.denyNonFastForwards\n> \n> > Also, is there an automated mechanism to ensure that the timeline\n> > stays clean? Say, force people to rebase their repositories before\n> > merging into the shared repository?\n> \n> In order to prevent merges, you will need to use a a receive-pack hook such as:\n> \n> http://lists.gnu.org/archive/html/bug-gnulib/2008-10/msg00221.html\n> \n> You might also consider something like gitosis/gitolite/gerrit\n> depending upon how formal you want to be.\n\nI think his only choice is to install a gitosis/gitolite/gerrit\nsolution.  Basically he needs to completely remove write access\nto the repository, so developers can't muck with it directly.\nThat requires one of those 3 tools to provide secured proxy access.\n\nOn top of those, yea, you would then also want to configure the\nreceive.denyDeletes and denyNonFastForwards you mentioned above,\nas well as maybe also write a custom update or pre-receive hook to\nprevent merges from entering the repository.\n\nThough preventing merges is a bit pedantic.  Eventually you'll want\nto use a merge rather than a rebase (e.g. merge in a maintenance\nbranch to pick up its bug fixes into the main development trunk).\n\n-- \nShawn.\n"}]}