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@intel.com> wrote:
quoted text
> [Sorry this has taken so long. Work was been eating my time.]

quoted text
> 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 ;-)

quoted text
> (The list may not be complete. I may have forgotten
> something.)

quoted text
> 1. Multiple duplicate keys parsing problem

quoted text
> This can happen when you have multiple people
> administering a repository. (Especially when those people
> are responsible for separate projects on the same server.

quoted text
> 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.

quoted text
> 2. Trees with working directories kills Gitosis

quoted text
> 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?

quoted text
> 3. Gitosis needs to have access to everything.

quoted text
> 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".

quoted text
> 4. Typos are deadly.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html