Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Playing with gerrit
Adolfo,

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 am not a fan of that requirement from gerrit myself, but one could argue that it makes for a much more legible history, since you have your features properly isolated in their commits. You do not lose the history of who did what, theirs comments and why they changed a particular review : that history is logged on gerrit instead, through the comments and various patch sets. For example, on https://git.eclipse.org/r/#/c/13903/, you can see a "big" feature-introducing commit. Gerrit keeps an history of the four distinct patch sets that have been created for that particular feature along with the comments we made during the reviews (on each patch set).

One would just need to look at the OCL repository's history to feel that gerrit is an improvement :p. I really have trouble finding out what commit introduced what change for which purpose in the (too) many branches in there. Gerrit's "one commit for a change" tends to make for a much clearer policy.

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 ?

That, I do not know. I rarely squash commits into one. Amending is usually much easier when you work on a change :).

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.

True enough, even very recently I've pushed to the repository a few changes for which the review had not been completed. But that can be avoided through a number of means :
  • disable the force push on your repository (you can no longer bypass gerrit)
    • On Compare, we've kept the force-push ability in order to avoid gerrit reviews when pushing the stream of very small changes I usually need when fixing build errors
  • Make it so that your "normal" remote's push configuration is for gerrit. If your look at http://wiki.eclipse.org/EMF_Compare/Gerrit#Adding_a_new_remote, we add a "review" remote to our repositories so that we can push to gerrit via "git push review". This configuration can also be made to be your default instead of a new remote, so that "git push" pushes on gerrit directly.

Laurent Goubet
Obeo

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

Back to the top