<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 8, 2015 at 5:47 AM, Matthew Brush <span dir="ltr"><<a href="mailto:mbrush@codebrainz.ca" target="_blank">mbrush@codebrainz.ca</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I propose that we disallow force pushing, rebasing, squashing, etc.<br>
on any PR until it is fully ready for final merging. […] ready for<br>
merging. At that point it _might_ make sense to fudge history and get<br>
rid of some noisy "fixup" commits[0].</blockquote></blockquote></span></blockquote><div><br></div><div>The question is how to detect the "fully ready for final merging" moment. For my patches the workflow typically looks like</div><div><br></div><div>1. I submit a patch</div><div>2. Colomban reviews it</div><div>3. I repush the patch with fixes</div><div>4. Colomban merges it</div><div><br></div><div>I kind of implicitly assume that after (3) the patch will be ready for merging (and it typically is) so I do the force push but of course there may be further comments.</div><div><br></div><div>For bigger patch sets one should choose what seems to be most practical. For instance for</div><div><br></div><div><a href="https://github.com/geany/geany/pull/488">https://github.com/geany/geany/pull/488</a><br></div><div><br></div><div>where there were many commits and also review comments I decided to create a separate pull request containing the fixes</div><div><br></div><div><a href="https://github.com/geany/geany/pull/505">https://github.com/geany/geany/pull/505</a><br></div><div><br></div><div>to preserve the comments in the original pull request. In this case adding fix commits would make things too messy.</div><div><br></div><div>So personally I wouldn't carve any rules in stone and would decide case to case. For bigger patches with many review comments it's probably best to ask the reviewer which way he prefers to have the fixes committed.</div><div><br></div><div>Cheers,</div><div><br></div><div>Jiri</div></div></div></div>