On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec <openst...@nemebean.com> wrote:

> On 08/05/2014 10:51 AM, ZZelle wrote:
> > Hi,
> >
> >
> > I like the idea  ... with complex change, it could useful for the
> > understanding to split it into smaller changes during development.
>
> I don't understand this.  If it's a complex change that you need
> multiple commits to keep track of locally, why wouldn't reviewers want
> the same thing?  Squashing a bunch of commits together solely so you
> have one review for Gerrit isn't a good thing.  Is it just the warning
> message that git-review prints when you try to push multiple commits
> that is the problem here?


When you're developing some big change you'll end up with trying dozens of
different approaches and make thousands of mistakes. For reviewers this is
just unnecessary noise (commit title "Scratch my last CR, that was
bullshit") while for you it's a precious history that can provide basis for
future research or bug-hunting.

Merges are one of the strong sides of Git itself (and keeping them very
easy is one of the founding principles behind it). With current workflow we
don't use them at all. master went too far forward? You have to do rebase
and screw all your local history and most likely squash everything anyway
because you don't want to fix commits with known bugs in them. With
proposed feature you can just do merge once and let 'git review' add some
magic without ever hurting your code.

And speaking about breaking down of change requests don't forget support
for change requests chains that this feature would lead to. How to you deal
with 5 consecutive change request that are up on review for half a year?
The only way I could suggest to my colleague at a time was "Erm... Learn
Git and dance with rebases, detached heads and reflogs!" My proposal might
take care of that too.

-- 

Kind regards, Yuriy.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to