<p dir="ltr"><br>
On Aug 6, 2014 7:21 AM, "Ben Nemec" <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>> wrote:<br>
><br>
> On 08/05/2014 03:14 PM, Yuriy Taraday wrote:<br>
> > On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>> wrote:<br>
> ><br>
> >> On 08/05/2014 10:51 AM, ZZelle wrote:<br>
> >>> Hi,<br>
> >>><br>
> >>><br>
> >>> I like the idea  ... with complex change, it could useful for the<br>
> >>> understanding to split it into smaller changes during development.<br>
> >><br>
> >> I don't understand this.  If it's a complex change that you need<br>
> >> multiple commits to keep track of locally, why wouldn't reviewers want<br>
> >> the same thing?  Squashing a bunch of commits together solely so you<br>
> >> have one review for Gerrit isn't a good thing.  Is it just the warning<br>
> >> message that git-review prints when you try to push multiple commits<br>
> >> that is the problem here?<br>
> ><br>
> ><br>
> > When you're developing some big change you'll end up with trying dozens of<br>
> > different approaches and make thousands of mistakes. For reviewers this is<br>
> > just unnecessary noise (commit title "Scratch my last CR, that was<br>
> > bullshit") while for you it's a precious history that can provide basis for<br>
> > future research or bug-hunting.<br>
><br>
> So basically keeping a record of how not to do it?  I get that, but I<br>
> think I'm more onboard with the suggestion of sticking those dead end<br>
> changes into a separate branch.  There's no particular reason to keep<br>
> them on your working branch anyway since they'll never merge to master.<br>
>  They're basically unnecessary conflicts waiting to happen.<br>
><br>
> ><br>
> > Merges are one of the strong sides of Git itself (and keeping them very<br>
> > easy is one of the founding principles behind it). With current workflow we<br>
> > don't use them at all. master went too far forward? You have to do rebase<br>
> > and screw all your local history and most likely squash everything anyway<br>
> > because you don't want to fix commits with known bugs in them. With<br>
> > proposed feature you can just do merge once and let 'git review' add some<br>
> > magic without ever hurting your code.<br>
><br>
> How do rebases screw up your local history?  All your commits are still<br>
> there after a rebase, they just have a different parent.  I also don't<br>
> see how rebases are all that much worse than merges.  If there are no<br>
> conflicts, rebases are trivial.  If there are conflicts, you'd have to<br>
> resolve them either way.<br>
><br>
> I also reiterate my point about not keeping broken commits on your<br>
> working branch.  You know at some point they're going to get<br>
> accidentally submitted. :-)<br>
><br>
> As far as letting git review do magic, how is that better than "git<br>
> rebase once and no magic required"?  You deal with the conflicts and<br>
> you're good to go.  And if someone asks you to split a commit, you can<br>
> do it.  With this proposal you can't, because anything but squashing<br>
> into one commit is going to be a nightmare (which might be my biggest<br>
> argument against this).<br>
><br>
> ><br>
> > And speaking about breaking down of change requests don't forget support<br>
> > for change requests chains that this feature would lead to. How to you deal<br>
> > with 5 consecutive change request that are up on review for half a year?<br>
> > The only way I could suggest to my colleague at a time was "Erm... Learn<br>
> > Git and dance with rebases, detached heads and reflogs!" My proposal might<br>
> > take care of that too.<br>
> ><br>
><br>
> How does this relate to commit series?  Squashing all the commits into<br>
> one isn't a solution to any of the problems with those (if it were, we<br>
> could do that today :-).<br>
><br>
> FWIW, I have had long-lived patch series, and I don't really see what is<br>
> so difficult about running git rebase master.  Other than conflicts, of<br>
> course, which are going to be an issue with any long-running change no<br>
> matter how it's submitted.  There isn't a ton of git magic involved.<br>
><br>
> So as you may have guessed by now, I'm opposed to adding this to<br>
> git-review.  I think it's going to encourage bad committer behavior<br>
> (monolithic commits) and doesn't address a use case I find compelling<br>
> enough to offset that concern.</p>
<p dir="ltr">+1</p>
<p dir="ltr">><br>
> /wall-o-text<br>
><br>
> -Ben<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>