<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 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">manuq@laptop.org</a>>:<br>
<div class="im">> 2013/3/28 Daniel Narvaez <<a href="mailto:dwnarvaez@gmail.com">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 class="HOEnZb"><div class="h5"><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">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">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>