On Fri, Aug 2, 2013 at 5:47 PM, Hervé BOUTEMY <herve.bout...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
