maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Broyer <t.bro...@gmail.com>
Subject Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Date Sat, 03 Aug 2013 12:52:18 GMT
On Fri, Aug 2, 2013 at 5:47 PM, Hervé BOUTEMY <herve.boutemy@free.fr> wrote:
> I didn't use gerrit nor have seen anybody using it.

Gerrit was created by and for Android: https://android-review.googlesource.com
It's used for Gerrit itself https://gerrit-review.googlesource.com
(dogfooding), Chromium and GWT, on Google infra.
It's also used by many companies contributing to Android (Sony, etc.),
and by Eclipse, Typo3, KDE, LibreOffice, Qt, OpenStack, etc.
https://code.google.com/p/gerrit/wiki/ShowCases
…and CloudFoundry:
http://blog.cloudfoundry.com/2012/04/11/the-new-cloudfoundry-org-gerrit-jenkins-github/

> But I hear about it more
> and more often as an argument why it makes git better than svn (even if I read
> that gerrit is a fork of rietveld, which is the same for subversion: but
> nobody even talks about it, don't know why).

Rietveld is hard to install outside AppEngine, that's probably why. I
would have loved to use it at work otherwise, instead of that crappy
ReviewBoard; we've fortunately moved to Git and Gerrit since then.

That said, Gerrit 1.x was started as a fork of Rietveld, but Gerrit
2.x has been rewritten from scratch in Java and GWT, built on top of
JGit.

> Is this pure theory? a dream? a reality for a minority of experts, talking
> about it loudly but no mere mortal can use it?
> (intentional provocational tone to motivate people who know to show me the
> direction to the light :) )
>
>> If a new feature is properly developed on a topic branch with commits
>> squashed, rewritten and organized as needed, the history can be laid out in
>> a very easy-to-understand manner: new features and bugfixes done in
>> properly isolated commits, unit tests added immediately thereafter, etc.
> yes, with git, you can: with git, so much things can be done.
> But once again, I didn't see anybody do it, because it's a lot of work.
> And it requires to be a git black belt.
> For the moment, just making a rebase before merging a branch seems hard for us
> mere mortals.

WAT? You can't wrap your head around a DAG of commits and you want us
other mere mortals to use a tool you're building on top of a DAG of
transitive dependencies? (intentionally provocative tone to motivate
you to reconsider your position about git). Git is easy to work with
when you think in terms of the DAG in your repo; no need to be a git
black belt for that.
I merely use 5 git commands on a daily basis (using "git gui" to do my
commits and deal with my working directory; pull, push, checkout and
"rebase -i"; merges are generally done by Gerrit, at the push of a
button; on a relatively big project like GWT, I tend to use gitk, "git
log --grep", "git grep" and "git blame" quite a lot too; and this only
works well if you have a "clean history", which you cannot have with a
"commit then review" approach – on master/trunk I mean – but of
course, because SVN doesn't give you tools to easily look back at your
commit history, you tend to not care that much about having a "clean
history"; "git svn" mitigates it a bit).

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message