<div dir="ltr">Maybe there is a hook that we can use?<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 10, 2013 at 10:24 AM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Martin,<br></div><br></div><div>Thanks for trying it out! I hope more reviewers will follow you :)<br>
</div><div><br>I tend to agree about the merge commit, especially for small patch sets.<br>
<br></div>A pull request is just a branch. If you click the (i) button in the pull request green box, you get instructions on how to pull it locally (they can probably be shortened a bit by avoiding to use a separate branch). Then with interactive rebase you can edit the commit logs and add the acked-by.<br>
<br></div><div>If you have a lot of patches the interactive rebase is going to be annoying. We could script that part, I would actually be surprised if no one has done it already.<br></div></div><div class="gmail_extra">
<div><div class="h5"><br>
<br><div class="gmail_quote">On 9 April 2013 23:29, Martin Abente <span dir="ltr"><<a href="mailto:martin.abente.lahaye@gmail.com" target="_blank">martin.abente.lahaye@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>Hello: <br><br></div><div>I was testing the workflow today (thanks a lot to manuq for the assistance) and it seems easy enough. The only thing that I didn't like was the merge-commit, IMHO is a little-bit noisy. I know the importance of leaving a trace about who's pushing the change, but a whole commit for that doesn't seem right to me.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">I got to push manuq changes without the the merge-commit, but it didn't leave any trace of me pushing it, which is something we require. So, does occur to someone a way to get the best from both worlds (IE, a way to have the acked-by) :)?<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Saludos,<br></div><div class="gmail_extra">Tincho.<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 9, 2013 at 12:55 PM, Manuel Quiñones <span dir="ltr"><<a href="mailto:manuq@laptop.org" target="_blank">manuq@laptop.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2013/4/8 Manuel Quiñones <<a href="mailto:manuq@laptop.org" target="_blank">manuq@laptop.org</a>>:<br>
<div>> 2013/3/28 Daniel Narvaez <<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>>:<br>
>> Hi,<br>
>><br>
>> I started experimenting a bit with github code reviews, with Walter as<br>
>> ginuea pig :) We wasn't too sure about stuff like rebasing, using<br>
>> separate branches etc, so tonight I played a bit myself with creating<br>
>> pull requests.<br>
>><br>
>> Something like the following might be a decent start for a workflow<br>
>><br>
>> 1 Create one branch per topic<br>
><br>
> 0. Fork<br>
><br>
> I forgot to do it in my first pull-request submission.<br>
<br>
</div>And add a remote for upstream. Example:<br>
<br>
git remote add upstream <a href="https://github.com/sugarlabs/sugar.git" target="_blank">https://github.com/sugarlabs/sugar.git</a><br>
<br>
Which is useful to keep your fork in sync. This is for the record, we<br>
need to write the documentation of the workflow.<br>
<div><div><br>
>><br>
>> git checkout -b topic1<br>
>><br>
>> 2 Make one or more commits<br>
>> 3 Push the branch<br>
>><br>
>> git push origin topic1<br>
>><br>
>> 4 Submit a pull request for the branch (web UI)<br>
>><br>
>> 5a The reviewer merges the patch.<br>
>> 5b The reviewer rejects the patch (and closes the request).<br>
>> 5c The reviewer requires changes (and closes the request).<br>
>><br>
>> If 5c:<br>
>><br>
>> 6 Make changes using interactive rebase<br>
>> (<a href="http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages" target="_blank">http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages</a>)<br>
>><br>
>> git rebase -i master<br>
>><br>
>> 7 Push the changes to another remote branch<br>
>><br>
>> git push origin topic1:topic1-try2<br>
>><br>
>> 8 Submit the new pull request (web UI)<br>
>><br>
>><br>
>> If someone has experience with github suggestions would be welcome.<br>
>> Otherwise I hope Walter will keep being the ginuea pig in this<br>
>> experiment :)<br>
>><br>
>> --<br>
>> Daniel Narvaez<br>
>> _______________________________________________<br>
>> Sugar-devel mailing list<br>
>> <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
>> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
><br>
><br>
><br>
> --<br>
> .. manuq ..<br>
<br>
<br>
<br>
--<br>
.. manuq ..<br>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br>Daniel Narvaez<br>
</font></span></div>
</blockquote></div><br></div>