<div dir="ltr">On 2 April 2013 16:43, Manuel Quiñones <span dir="ltr"><<a href="mailto:manuq@laptop.org" target="_blank">manuq@laptop.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 7 Push the changes to another remote branch<br><div class="im">
<br>
</div>Is there a need for a new branch for each pull request?  Pushing again<br>
to the topic1 will automatically update the pull request in github.<br></blockquote><div><br></div><div>The problem is when rebasing (i.e. making changes to any of the already reviewed commits), which is a very very frequent case... You either need to use another branch or to git push -f, which I'm not too comfortable with, I'm worried I would it use it accidentally somewhere else if I got used to it...<br>
<br></div><div>Do you know how people generally deals with that case?<br><br></div><div>The only other option I can think of is to fix the reviewer complaints in another commit, which I don't like much because it makes a mess of the history.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think we should have shortcuts too, to not block too much.  For a<br>
simple patch for example, the maintainer could be able to add minor<br>
tweaks to the pull request and do a manual merge, instead of asking<br>
another reviewing loop.<br></blockquote><div><br></div><div>Yup. <br></div></div></div></div>