"Olsen, Alan R" <alan.r.olsen@intel.com> wrote:
quoted text
> 
> 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.

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

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