<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 5, 2014 at 5:27 PM, Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


-1 to this as git-review default behaviour.</blockquote><div><br></div><div style>I don't suggest to make it the default behavior. As I wrote there will definitely be a config option that would turn it on.</div><div>

 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Ideally, branches should be identical in between Gerrit and local Git.<br></blockquote><div><br></div><div style>

The thing is that there's no feature branches in Gerrit. Just some number of independent commits (patchsets). And you'll even get log of those locally in special refs!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


I can understand some exceptions where developers want to work on intermediate commits and squash them before updating Gerrit, but in that case, I can't see why it needs to be kept locally. If a new patchset has to be done on patch A, then the local branch can be rebased interactively on last master, edit patch A by doing an intermediate patch, then squash the change, and pick the later patches (B to E)<br>

</blockquote><div><br></div><div style>And that works up to the point when your change requests evolves for several months and there's no easy way to dig up why did you change that default or how did this algorithm ended up in such shape. You can't simply run bisect to find what did you break since 10 patchsets ago. Git has been designed to be super easy to keep branches and most of them - locally. And we can't properly use them.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That said, I can also understand that developers work their way, and so could dislike squashing commits, hence my proposal to have a --no-squash option when uploading, but use with caution (for a single branch, how many dependencies are outdated in Gerrit because developers work on separate branches for each single commit while they could work locally on a single branch ? I can't iimagine how often errors could happen if we don't force by default to squash commits before sending them to Gerrit)<br>

</blockquote><div><br></div><div style>I don't quite get the reason for --no-squash option. With current git-review there's no squashing at all. You either upload all outstanding commits or you go a change smth by yourself. With my suggested approach you don't squash (in terms of rebasing) anything, you just create a new commit with the very same contents as in your branch.</div>

</div><div><br></div>-- <br><br><div>Kind regards, Yuriy.</div>
</div></div>