thank you Curtis: all the pointers you gave are of great value! I perfectly understand your Githubs examples: pull requests + work to give pull requests most chances to be accepted In fact, in our case, for somebody having commit privileges, using such pull requests isn't the first thing I would have thought, but yes, it is a good Review Then Commit tooling
For somebody with commit privileges, would you find any key difference with a branch on ASF Git + discussion on mailing list before merging into master? For gerrit, now I see what it looks like: seems really more complex than GitHubs pull requests. Don't know when such tooling starts to be really useful Thanks again for your pointers: today, I learned something useful, it's a good day Notice I'm having holidays and won't be on the ML for 2 weeks: I won't be able to continue the discussion, even if really instructive Regards, Hervé Le vendredi 2 août 2013 11:13:50 Curtis Rueden a écrit : > Hi Herve, > > > I didn't use gerrit nor have seen anybody using it. ... Is this pure > > theory? a dream? a reality for a minority of experts, talking about it > > loudly but no mere mortal can use it? > > Google uses it (of course). For example, for Chromium: > https://gerrit.chromium.org/ > Kitware uses it. ITK, VTK, etc.: http://review.source.kitware.com/ > I'm sure there are many others. > > Personally my colleagues and I don't use it; we use GitHub's code review > mechanism which is simple and effective. You can comment on any Pull > Request, and on any line of any commit. > > > I hear about it more and more often as an argument why it makes git > > better than svn > > It was not my goal to argue that "Gerrit makes Git better than SVN" but > rather than good code review tools make code review *much* easier. > > Git is better than SVN for many, many reasons that have nothing to do with > code review tools. :-P > > > 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. > > As a programmer, revision control in one of your bread-and-butter tools. > Shouldn't you be taking the time to become a VCS black belt? Doing so will > save you loads of time in the long run, for the same reasons that becoming > a command line master, or an IDE master, or a master of *any* effective > productivity tool, will. Embrace Larry Wall's virtues of the programmer -- > laziness, impatience and hubris -- and always seek the better, faster path! > Computers are different than other skill sets: a professional sprinter may > be able to sprint 2x or 3x or even 5x faster than you, but a professional > programmer can accomplish a task on a computer thousands or even millions > of times faster than a neophyte... *if* the programmer has a thirst for > knowledge and self-improvement. > > </soapbox> > > Anyway, yes, my colleagues and I *do* use Git in this way: work on topic > branches, rewrite history to make review easier, and sometimes file Pull > Requests on GitHub to specifically invite review for possibly disruptive > changes. > > I'm not really sure what to point you at here, other than the "Contribution > Activity" section of my GitHub page: > https://github.com/ctrueden > Of course, it is changing all the time... > > Regards, > Curtis > > On Fri, Aug 2, 2013 at 10:47 AM, Hervé BOUTEMY <herve.bout...@free.fr>wrote: > > Le vendredi 2 août 2013 10:08:42 Curtis Rueden a écrit : > > > True, and it is good to warn about this. However, ultimately I think Git > > > > is > > > > > a better choice (than SVN) because it often makes code review much > > > > easier. > > I didn't use gerrit nor have seen anybody using it. 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). > > 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. > > > > > If > > > a commit is too large or conflates many different changes, Git provides > > > > the > > > > > tools to split up that work for rereview. > > > > > > Again, thanks for writing this. > > > > +1 > > I like it too > > > > Regards, > > > > Hervé > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
