I can't speak for gitosis -- I thank my stars every day that the gitosis author did not reply to my emails back then, because otherwise there may not have been a gitolite. But I will try and address a couple of points which strike me as important, especially ones that affect gitolite also, just for completeness. On Fri, Oct 29, 2010 at 2:28 AM, Olsen, Alan R <alan.r.olsen@xxxxxxxxx> wrote: > [Sorry this has taken so long. Work was been eating my time.] > Here 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. <wink, wink> I think that is the first issue ;-) > (The list may not be complete. I may have forgotten > something.) > 1. Multiple duplicate keys parsing problem > This can happen when you have multiple people > administering a repository. (Especially when those people > are responsible for separate projects on the same server. > You 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. Gitolite will do the same thing. This is an artifact of the fact that neither of them is looking *inside* the key and comparing with others, coupled with the fact that sshd does a linear scan, and when it finds a match it goes with it. I can tell you that in gitolite, I have no intention of adding that check by comparing the contents of the keys. However, gitolite does have "sshkeys-lint" which will catch the problem and tell you that second key will be ignored by sshd. You have to run this manually though. > 2. Trees with working directories kills Gitosis > If 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. Good. A server side repo has no business having a working tree ;-) Gitolite was modelled after gitosis, although it's hard to imagine that now, seeing how far apart they are today. Server side repos == bare repos. Bare repos == .git suffix as a convention in git-land. This convention becomes "standard" in gitolite. "cloning code into the repo on the local machine" -- if I assume git clone, just add --bare maybe? > 3. Gitosis needs to have access to everything. > If 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. Gitolite will only care about directories ending in ".git". > 4. Typos are deadly. > If 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. What I found more problematic was it would silently ignore typos such as "member" instead of "members". Gitolite will show you lots of errors. You can still push up a botched-config (syntactically correct but you managed to lock yourself out by typoing your own name!), but you don't have to throw in the towel -- there is "gl-dont-panic" (written 2 months after "towel day", to my eternal regret ;-) Sitaram -- 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