"Olsen, Alan R" [off-list ref] writes:
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. (The list may not be complete. I may have
forgotten something.)
For completeness (but I think you know it already): gitolite is an
alternative to gitosis, and it is maintained.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
From: Matthieu Moy [mailto:Matthieu.Moy@grenoble-inp.fr]
Sent: Thursday, October 28, 2010 2:43 PM
To: Olsen, Alan R
Cc: git@vger.kernel.org
Subject: Re: Bugs in Gitosis
"Olsen, Alan R" [off-list ref] writes:
quoted
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. (The list may not be complete. I may have
forgotten something.)
For completeness (but I think you know it already): gitolite is an
alternative to gitosis, and it is maintained.
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.
On Fri, Oct 29, 2010 at 3:52 AM, Olsen, Alan R [off-list ref] wrote:
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.
For the real reason I added that into the docs, see
http://github.com/sitaramc/gitolite/commit/10289c6d6494e7aa4204dfe29afec7535c1aa1a2
If <any other software> wants to add *other* files into repos that
gitolite does not need, that is perfectly fine. Gitolite does not
expect to be "sole control", but just "don't mess with my stuff and
we'll get along fine".
However, I wasn't aware that it is even *possible* to run gerrit and
gitolite together. Gerrit has its own customised ssh daemon, its own
customised "git", and so on.
I also fail to understand why you need gitolite if you're using
gerrit. I believe gerrit can do all the access control that gitolite
can do. See http://github.com/sitaramc/gitolite/blob/pu/contrib/gerrit.mkd
for a comparision
regards
sitaram
-----Original Message-----
From: Sitaram Chamarty [mailto:sitaramc@gmail.com]
Sent: Thursday, October 28, 2010 5:02 PM
To: Olsen, Alan R
Cc: Matthieu Moy; git@vger.kernel.org
Subject: Re: Bugs in Gitosis
On Fri, Oct 29, 2010 at 3:52 AM, Olsen, Alan R [off-list ref] wrote:
quoted
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.
For the real reason I added that into the docs, see
http://github.com/sitaramc/gitolite/commit/10289c6d6494e7aa4204dfe29afec7535c1aa1a2
If <any other software> wants to add *other* files into repos that
gitolite does not need, that is perfectly fine. Gitolite does not
expect to be "sole control", but just "don't mess with my stuff and
we'll get along fine".
However, I wasn't aware that it is even *possible* to run gerrit and
gitolite together. Gerrit has its own customised ssh daemon, its own
customised "git", and so on.
Gerrit runs its ssh daemon on another port. If you run them both as the same user, it works fine.
I also fail to understand why you need gitolite if you're using
gerrit. I believe gerrit can do all the access control that gitolite
can do. See http://github.com/sitaramc/gitolite/blob/pu/contrib/gerrit.mkd
for a comparision
We use gitosis currently for back-end management.
Gerrit 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.)
There are also some people (me for example) who loath the Repo command and prefer to work using git.
I am hoping we can migrate to Gitolite. I am going to set up a test server to see if I can identify problems.
"Olsen, Alan R" [off-list ref] wrote:
Gerrit does not add existing projects well. Pushing the kernel
project into Gerrit causes one entry to approve per commit. That
swamps the server.
Don't push to refs/for/master. Grant yourself Push Branch +1
(or +2 if you need to create the branch) and push directly to
refs/heads/master like you would with Gitolite, Gitosis or any
other Git repository. Gerrit won't create a change record, and
thus won't be swamped.
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.)
I think it handles rebases about as well as any other Git tool, you
need to enable Push +3 to permit force push/rewind of the relevant
branches, and then actually do the force push. Any pending commit
will need to be rebased. Which is also true for just about any
workflow except the classic Linux kernel "format-patch and email"
model. Switching to gitolite probably won't easy the rebase pain.
FWIW, the Google kernel developers have their Gerrit instance
configured to use the cherry-pick submit type on their kernel
repositories, which makes changes submittable across rebases,
because its emulating the format-patch->email->am workflow that
is traditionally used for kernel development.
There are also some people (me for example) who loath the Repo
command and prefer to work using git.
I'm also among those people, as are many of Google's kernel
developers. We just use git push to talk to Gerrit... and
that is one of the primary reasons it embeds its own SSHD.
--
Shawn.