{"thread":{"id":"25583","subject":"Bugs in Gitosis","startedAt":"2010-10-28T20:58:11Z","lastAt":"2010-11-01T17:32:02Z","messageCount":7,"participants":["Olsen, Alan R","Matthieu Moy","Sitaram Chamarty","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"154677","messageId":"26E9B811E137AB4B95200FD4C950886BA9665D70@orsmsx507.amr.corp.intel.com","threadId":"25583","inReplyTo":null,"subject":"Bugs in Gitosis","fromName":"Olsen, Alan R","fromEmail":"alan.r.olsen@intel.com","sentAt":"2010-10-28T20:58:11Z","receivedAt":"2010-10-28T20:58:11Z","isPatch":false,"sender":{"key":"alan.r.olsen@intel.com","avatar":null},"body":"[Sorry this has taken so long. Work was been eating my time.]\n\nHere is my list of current outstanding issues with Gitosis. I do not have fixes for these at the moment, but people and web indexes should be aware of the problems. The author of Gitosis seems to have been taken off-line. (The list may not be complete. I may have forgotten something.)\n\n1. Multiple duplicate keys parsing problem\n\nThis can happen when you have multiple people administering a repository. (Especially when those people are responsible for separate projects on the same server.\n\nYou have a.pub and b.pub. These are both the public key for \"Bob\". (The same exact key in two files.) Any group that a.pub is added to Bob will have access to. Any group that b.pub is added to that does not contain a.pub Bob will not have access to. (It seems to sort the keys and only sees the first occurrence of the key, not all occurrences. \n\n2. Trees with working directories kills Gitosis\n\nIf any of the repositories in the repository have a working directory, Gitosis will fail on a push to gitosis-admin with a bunch of Python barfage. (I don't have an example at hand, but if you look at the code, it is looking at \".git\".) This usually happens when someone tries to shortcut the process by cloning code into the repo on the local machine.\n\n3. Gitosis needs to have access to everything.\n\nIf your mount point for the repository is /repo you have to create a directory under this, else /repo/lost+found prevents Gitosis for initializing correctly. It is a permissions issue.\n\n4. Typos are deadly.\n\nIf you push a gitosis.conf file to gitosis-admin that has a non-parseable typo, gitosis will have problems. The immediate effect is that the authorized-keys file does not get updated. (New keys do not get added to the file, but existing ones work up except for the typo areas.) The only way to fix this is to hand-correct the copy on the server. Rerunning the gitosis-init script on the server will fix a lot of problems and does not overwrite existing configs.\n\nThose are the ones I can remember at the moment. As soon as I send this I will remember more.\n\nHope this helps.\n"},{"id":"154681","messageId":"vpq8w1if0yy.fsf@bauges.imag.fr","threadId":"25583","inReplyTo":"26E9B811E137AB4B95200FD4C950886BA9665D70@orsmsx507.amr.corp.intel.com","subject":"Re: Bugs in Gitosis","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-10-28T21:42:45Z","receivedAt":"2010-10-28T21:42:45Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"Olsen, Alan R\" writes:\n\n> Here is my list of current outstanding issues with Gitosis. I do\n> not have fixes for these at the moment, but people and web indexes\n> should be aware of the problems. The author of Gitosis seems to have\n> been taken off-line. (The list may not be complete. I may have\n> forgotten something.)\n\nFor completeness (but I think you know it already): gitolite is an\nalternative to gitosis, and it is maintained.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"154693","messageId":"26E9B811E137AB4B95200FD4C950886BA9665E50@orsmsx507.amr.corp.intel.com","threadId":"25583","inReplyTo":"vpq8w1if0yy.fsf@bauges.imag.fr","subject":"RE: Bugs in Gitosis","fromName":"Olsen, Alan R","fromEmail":"alan.r.olsen@intel.com","sentAt":"2010-10-28T22:22:19Z","receivedAt":"2010-10-28T22:22:19Z","isPatch":false,"sender":{"key":"alan.r.olsen@intel.com","avatar":null},"body":">From: Matthieu Moy [mailto:Matthieu.Moy@grenoble-inp.fr] \n>Sent: Thursday, October 28, 2010 2:43 PM\n>To: Olsen, Alan R\n>Cc: git@vger.kernel.org\n>Subject: Re: Bugs in Gitosis\n\n>\"Olsen, Alan R\" writes:\n\n>> Here is my list of current outstanding issues with Gitosis. I do\n>> not have fixes for these at the moment, but people and web indexes\n>> should be aware of the problems. The author of Gitosis seems to have\n>> been taken off-line. (The list may not be complete. I may have\n>> forgotten something.)\n\n>For completeness (but I think you know it already): gitolite is an\n>alternative to gitosis, and it is maintained.\n\nDoes gitolite play well with Gerrit? I note in the docs that it does not react well to files under its control being messed with.\n"},{"id":"154704","messageId":"AANLkTi=pdSyjd5ACu8D_Yio5KX68W2n0e=LXXeTw70mS@mail.gmail.com","threadId":"25583","inReplyTo":"26E9B811E137AB4B95200FD4C950886BA9665D70@orsmsx507.amr.corp.intel.com","subject":"Re: Bugs in Gitosis","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2010-10-28T23:54:54Z","receivedAt":"2010-10-28T23:54:54Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"I can't speak for gitosis -- I thank my stars every day that\nthe gitosis author did not reply to my emails back then,\nbecause otherwise there may not have been a gitolite.\n\nBut I will try and address a couple of points which strike\nme as important, especially ones that affect gitolite also,\njust for completeness.\n\nOn Fri, Oct 29, 2010 at 2:28 AM, Olsen, Alan R wrote:\n> [Sorry this has taken so long. Work was been eating my time.]\n\n> Here is my list of current outstanding issues with\n> Gitosis.  I do not have fixes for these at the moment, but\n> people and web indexes should be aware of the problems.\n> The author of Gitosis seems to have been taken off-line.\n\n I think that is the first issue ;-)\n\n> (The list may not be complete. I may have forgotten\n> something.)\n\n> 1. Multiple duplicate keys parsing problem\n\n> This can happen when you have multiple people\n> administering a repository. (Especially when those people\n> are responsible for separate projects on the same server.\n\n> You have a.pub and b.pub. These are both the public key\n> for \"Bob\". (The same exact key in two files.)  Any group\n> that a.pub is added to Bob will have access to. Any group\n> that b.pub is added to that does not contain a.pub Bob\n> will not have access to.  (It seems to sort the keys and\n> only sees the first occurrence of the key, not all\n> occurrences.\n\nGitolite will do the same thing. This is an artifact of the\nfact that neither of them is looking *inside* the key and\ncomparing with others, coupled with the fact that sshd does\na linear scan, and when it finds a match it goes with it.\n\nI can tell you that in gitolite, I have no intention of\nadding that check by comparing the contents of the keys.\n\nHowever, gitolite does have \"sshkeys-lint\" which will catch\nthe problem and tell you that second key will be ignored by\nsshd. You have to run this manually though.\n\n> 2. Trees with working directories kills Gitosis\n\n> If any of the repositories in the repository have a\n> working directory, Gitosis will fail on a push to\n> gitosis-admin with a bunch of Python barfage.  (I don't\n> have an example at hand, but if you look at the code, it\n> is looking at \".git\".) This usually happens when someone\n> tries to shortcut the process by cloning code into the\n> repo on the local machine.\n\nGood. A server side repo has no business having a working\ntree ;-)\n\nGitolite was modelled after gitosis, although it's hard to\nimagine that now, seeing how far apart they are today.\n\nServer side repos == bare repos. Bare repos == .git suffix\nas a convention in git-land. This convention becomes\n\"standard\" in gitolite.\n\n\"cloning code into the repo on the local machine\" -- if I\nassume git clone, just add --bare maybe?\n\n> 3. Gitosis needs to have access to everything.\n\n> If your mount point for the repository is /repo you have\n> to create a directory under this, else /repo/lost+found\n> prevents Gitosis for initializing correctly. It is a\n> permissions issue.\n\nGitolite will only care about directories ending in \".git\".\n\n> 4. Typos are deadly.\n\n> If you push a gitosis.conf file to gitosis-admin that has\n> a non-parseable typo, gitosis will have problems. The\n> immediate effect is that the authorized-keys file does not\n> get updated. (New keys do not get added to the file, but\n> existing ones work up except for the typo areas.) The only\n> way to fix this is to hand-correct the copy on the server.\n> Rerunning the gitosis-init script on the server will fix a\n> lot of problems and does not overwrite existing configs.\n\nWhat I found more problematic was it would silently ignore\ntypos such as \"member\" instead of \"members\".\n\nGitolite will show you lots of errors.\n\nYou can still push up a botched-config (syntactically\ncorrect but you managed to lock yourself out by typoing your\nown name!), but you don't have to throw in the towel --\nthere is \"gl-dont-panic\" (written 2 months after \"towel\nday\", to my eternal regret ;-)\n\nSitaram\n"},{"id":"154705","messageId":"AANLkTik+CcuAtB=t5GgP9C-WrJRZt-LDNs3wUChhKTuz@mail.gmail.com","threadId":"25583","inReplyTo":"26E9B811E137AB4B95200FD4C950886BA9665E50@orsmsx507.amr.corp.intel.com","subject":"Re: Bugs in Gitosis","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2010-10-29T00:02:14Z","receivedAt":"2010-10-29T00:02:14Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Fri, Oct 29, 2010 at 3:52 AM, Olsen, Alan R wrote:\n\n> Does gitolite play well with Gerrit? I note in the docs that it does not react well to files under its control being messed with.\n\nFor the real reason I added that into the docs, see\nhttp://github.com/sitaramc/gitolite/commit/10289c6d6494e7aa4204dfe29afec7535c1aa1a2\n\nIf wants to add *other* files into repos that\ngitolite does not need, that is perfectly fine. Gitolite does not\nexpect to be \"sole control\", but just \"don't mess with my stuff and\nwe'll get along fine\".\n\nHowever, I wasn't aware that it is even *possible* to run gerrit and\ngitolite together. Gerrit has its own customised ssh daemon, its own\ncustomised \"git\", and so on.\n\nI also fail to understand why you need gitolite if you're using\ngerrit. I believe gerrit can do all the access control that gitolite\ncan do. See http://github.com/sitaramc/gitolite/blob/pu/contrib/gerrit.mkd\nfor a comparision\n\nregards\n\nsitaram\n"},{"id":"154934","messageId":"26E9B811E137AB4B95200FD4C950886BA96667EA@orsmsx507.amr.corp.intel.com","threadId":"25583","inReplyTo":"AANLkTik+CcuAtB=t5GgP9C-WrJRZt-LDNs3wUChhKTuz@mail.gmail.com","subject":"RE: Bugs in Gitosis","fromName":"Olsen, Alan R","fromEmail":"alan.r.olsen@intel.com","sentAt":"2010-11-01T17:23:43Z","receivedAt":"2010-11-01T17:23:43Z","isPatch":false,"sender":{"key":"alan.r.olsen@intel.com","avatar":null},"body":"\n\n>-----Original Message-----\n>From: Sitaram Chamarty [mailto:sitaramc@gmail.com] \n>Sent: Thursday, October 28, 2010 5:02 PM\n>To: Olsen, Alan R\n>Cc: Matthieu Moy; git@vger.kernel.org\n>Subject: Re: Bugs in Gitosis\n\n>On Fri, Oct 29, 2010 at 3:52 AM, Olsen, Alan R wrote:\n\n>> Does gitolite play well with Gerrit? I note in the docs that it does not react well to files under its control being messed with.\n\n>For the real reason I added that into the docs, see\n>http://github.com/sitaramc/gitolite/commit/10289c6d6494e7aa4204dfe29afec7535c1aa1a2\n\n>If wants to add *other* files into repos that\n>gitolite does not need, that is perfectly fine. Gitolite does not\n>expect to be \"sole control\", but just \"don't mess with my stuff and\n>we'll get along fine\".\n\n>However, I wasn't aware that it is even *possible* to run gerrit and\n>gitolite together. Gerrit has its own customised ssh daemon, its own\n>customised \"git\", and so on.\n\nGerrit runs its ssh daemon on another port. If you run them both as the same user, it works fine.\n\n>I also fail to understand why you need gitolite if you're using\n>gerrit. I believe gerrit can do all the access control that gitolite\n>can do. See http://github.com/sitaramc/gitolite/blob/pu/contrib/gerrit.mkd\n>for a comparision\n\nWe use gitosis currently for back-end management.\n\nGerrit does not add existing projects well. Pushing the kernel project into Gerrit causes one entry to approve per commit. That swamps the server. Gerrit does not have a way of handling rebases very well. (We have projects that have a regular consolidation on the end of the development trees.)\n\nThere are also some people (me for example) who loath the Repo command and prefer to work using git.\n\nI am hoping we can migrate to Gitolite. I am going to set up a test server to see if I can identify problems.\n\n"},{"id":"154936","messageId":"20101101173202.GA22725@spearce.org","threadId":"25583","inReplyTo":"26E9B811E137AB4B95200FD4C950886BA96667EA@orsmsx507.amr.corp.intel.com","subject":"Re: Bugs in Gitosis","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-11-01T17:32:02Z","receivedAt":"2010-11-01T17:32:02Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Olsen, Alan R\" wrote:\n> \n> Gerrit does not add existing projects well. Pushing the kernel\n> project into Gerrit causes one entry to approve per commit. That\n> swamps the server.\n\nDon't push to refs/for/master. Grant yourself Push Branch +1\n(or +2 if you need to create the branch) and push directly to\nrefs/heads/master like you would with Gitolite, Gitosis or any\nother Git repository. Gerrit won't create a change record, and\nthus won't be swamped.\n\n> Gerrit does not have a way of handling rebases\n> very well. (We have projects that have a regular consolidation on\n> the end of the development trees.)\n\nI think it handles rebases about as well as any other Git tool, you\nneed to enable Push +3 to permit force push/rewind of the relevant\nbranches, and then actually do the force push. Any pending commit\nwill need to be rebased. Which is also true for just about any\nworkflow except the classic Linux kernel \"format-patch and email\"\nmodel. Switching to gitolite probably won't easy the rebase pain.\n\nFWIW, the Google kernel developers have their Gerrit instance\nconfigured to use the cherry-pick submit type on their kernel\nrepositories, which makes changes submittable across rebases,\nbecause its emulating the format-patch->email->am workflow that\nis traditionally used for kernel development.\n\n> There are also some people (me for example) who loath the Repo\n> command and prefer to work using git.\n\nI'm also among those people, as are many of Google's kernel\ndevelopers. We just use git push to talk to Gerrit... and\nthat is one of the primary reasons it embeds its own SSHD.\n\n-- \nShawn.\n"}]}