[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] Playing with gerrit
|
Hi Laurent,
Thank you very much for your comments.
Mine in-lined below.
Cheers,
Adolfo.
On 18/07/2013 08:23, Laurent Goubet wrote:
Hi,
You might want to look at what we ask for reviews on compare
(http://wiki.eclipse.org/EMF_Compare/Gerrit#Requesting_a_Review) from
both contributors and commiters, or what EGit does, which is pretty
similar
(http://wiki.eclipse.org/EGit/Contributor_Guide#Contributing_Patches).
Useful links. Thanks.
Basically : you need a Change-Id, and I think it would be better for you
to configure the OCL repository to require an explicit Change-Id in the
commit message (see also
https://bugs.eclipse.org/bugs/show_bug.cgi?id=400207). These ids can be
automatically generated by EGit, or through a commit-hook if you wish to
use the command line.
I learnt about this yesterday after some experimentation and reading.
Indeed, first commit has the automatic computed change-id. Other commits
need
A gerrit "review" is tied to this Id, which also
mandates that one review = one commit. This is also what allows you to
simply cherry-pick said commit from gerrit, change it, then push it
again to update the review with your own changes.
To be honest I don't like this. Merging a potential long bunch of
commits, in which everyone has its purpose and comments, in just one,
makes me lose one of the essence of this agile quick changes oriented
methodology which I love.
I'll try this squeezed commit, perhaps it's the cause of the push
rejection. I guess that EGit doesn't have a way to this via UI, does it ?
as for abandonning a change : "-2" in code-review is a veto which will
prevent anyone from submitting the patch, but will not prevent new patch
sets to be pushed to update the same review.
This makes sense to me, in the same way I didn't expect my push be
successful, but this trial was quick and free :)
"my Gerrit push (refs/for/master) is rejected. " : you should have had a
more verbose reject message to tell you what was wrong.
Right. Now what I know what "squeez" is, I've noticed the error message
hint:
squash commits first
Processing changes: refs: 1
Processing changes: refs: 1, done
And yes, enabling automatic hudson jobs to review the changes is one of
the selling points of gerrit for us, you can look at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=398289 for how we
requested it. For the rest, IIRC you just need to configure it to be
triggerred by a "gerrit event" in the jobs configuration (build trigger
=> gerrit event, then in "gerrit trigger", give it the path of your
gerrit project (ocl/org.eclipse.ocl)).
Thanks, I'll have a look to this. However I'm not convinced about this
megacommits for non-trivial developments. Very useful for
trivial/occasional fixes (specially with automatic hudson tests
verification).
Some feelings I've got so far. It also requires be more careful when
committing/pushing, which could be error prone. Now we have push and
push to gerrit, I'm used to "commit and push" button (a normal push). It
sounds dangerous.
Laurent Goubet
Obeo
On 17/07/2013 19:29, Adolfo Sanchez-Barbudo Herrera wrote:
Hi Ed,
Playing around with Gerrit and after having some reading, I have some
comments:
After pushing to Gerrit a second commit for the fix you blocked. Now
we have two pending changes to review:
a) https://git.eclipse.org/r/#/c/14619/1
b) https://git.eclipse.org/r/#/c/14620/1 (which depends on a))
Which is not definitely what I would have wished
In Gerrit documentation I've found:
"To add an additional patch set to a change, ensure Change-Id lines
were created in the original commit messages"
So my second commit should have included the following line in the
commit message:
Change-Id: I5814ceb238e511a8a56420f54550a8c3389c8c18
Next try. I've commited a new change using the Change-Id of b), to see
if I obtain a second patch set for the second Gerrit change. However
my Gerrit push (refs/for/master) is rejected.
I decided to reject (-2) my Gerrit change, just in the improvable case
Gerrit-enabled GIT repo were so clever to not accept changes until
some reviewing actions were taken. It was not the case .
I'll go on investigations tomorrow.
BTW, If I'm not wrong we can configure hudson jobs (branch tests for
example?) to make it autimotically verify a Gerrit change. This sounds
quite useful.
P.S: Gerrit doc:
http://gerrit-documentation.googlecode.com/svn/Documentation/2.6/index.html
Cheers,
Adolfo.
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
