[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] Playing with gerrit
|
On 18/07/2013 10:42, Laurent Goubet wrote:
Adolfo,
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).
I prefer, features isolated by branching/merging. In one commit, you
can't distinguish useful changes from those not so useful (regenarated
code, releng changes). Moreover, if several people have been
participating on a feature I don't know how authoring will be attributed
in a squashed commit. I guess that in this situations, there will be
different gerrit code review (dependent?). Anyway, in principle having
to squash commits to request code review doesn't sound good to me.
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'd have to think how our current workflow (branches policy for example)
would change with gerrit. Actually, I'd like to see what happens when a
change is successfully reviewed and submitted. My current gerrit
experiment is currently based on master's commits. Many concerns:
- Are you, replacing a branch per feature/bug policy with this Gerrit
usage ?
- What happens if the are several live pending code reviews?.
- Are they automatically merged when approved in case other approved
reviews arrived before?
- What about of integrity/integration of the merged independent reviews
(one could break the other)? What about if there are conflicts?
To me it looks like we still need a branches based development. In that
case, rather than a clearer history one commit per feature/bug only
ensures a shorter one ^^.
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)
o 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
Yes, having to pass through gerrit doesn't make sense. It would have to
be a useless workflow of "I send a code review request", and "I approve
my self".
* 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.
Currently, my origin points to gerrit (Remote Push URL
git.eclipse.org:29418/ocl/org.eclipse.ocl.git)
I don't know how this internally works, but my feelings are that we only
have one remote repo. So a normal push will always udpate our unique GIT
repo. The "push to gerrit" pushes to a different refs (refs/for rather
than refs/heads) which in somehow are not exposed in the remote repo
(nobody can fetch those refs, when fetching from the repository).
Let's see if I finally complete a Gerrit contribution to see how the
repository looks like. Meanwhile I'll login to build.eclipse.org to have
a look via command line.
Cheers,
Adolfo.
--
Laurent Goubet
Obeo
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
