[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mdt-ocl.dev] Playing with gerrit
|
Hi Ed,
When we think that the new feature is
ready, we prepare it for review by squashing the commits into a
single one with a proper commit message, which we push for
review. What you see in the review I've linked here
(https://git.eclipse.org/r/#/c/13903/) is the result of such a
squash.
For a single change I certainly prefer to compare the
start/finish; I don't have time to study the mistakes that were
made along the way. Unfortunately Adolfo's second try at a review
request failed to squash correctly, so I'm a bit worried that an
intelligent user is making such a mess of a trivial change. I'm
not impressed by the web interface to Gerrit and apparently there
is no working EGIT integration, so I had to change to Eclipse,
navigate to the file to verify that the Gerrit display was wrong.
It takes a while to familiarize with the Web UI of Gerrit... and
even then it isn't that good a user experience. The Mylyn
integration for gerrit seems quite good, but I haven't taken the
time yet to check it out (http://www.eclipse.org/reviews/).
It's
'just' a matter of better discipline to try to avoid two
improvements getting tangled, which is very difficult unless you
have a very fast review response, and that is counterproductive
because often I like an improvement to have a little time to
settle since it was often triggered by another problem, and may
deserve further work.
You can leave reviews pending for a long while, we actually do for
some of ours. My "initial" process for working with Gerrit was quite
messy, but it did the trick :
- checkout master
- work as usual
- commit (a)
- push a for review
- some more work
- commit b
- once I am satisfied with b
- It b depends on changes introduced by a, nothing to do, push
for review
- if it does _not_ depend on a, interactive rebase to remove
the dependency (just change the order so that b comes before
a), push b for review.
Nothing prevents you from removing 'a' altogether from your clone
since you can just cherry-pick it again from gerrit if it needs
improvements. You can stop playing around with 'a' once its review
has been approved and submitted on the remote. Though this worked,
it was the lazy way of doing things.
A better workflow is to really start taking advantage of branches.
- checkout master
- create topic branch topic_a
- work
- commit a
- push for review against master
- checkout master
- create topic branch topic_b
- work
- commit b
- push for review against master
This second one is already really close to what you're doing if I
understand correctly, so I thought you wouldn't have much trouble
adopting gerrit :). All that you really need to take care of is to
have independent commits, or to make sure that the dependencies are
legitimate.
|
begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr">Obeo</a>
email;internet:laurent.goubet@xxxxxxx
url:http://www.obeo.fr
version:2.1
end:vcard