[Sugar-devel] Github review workflow

Martin Abente martin.abente.lahaye at gmail.com
Tue Apr 9 17:29:26 EDT 2013


Hello:

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.

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) :)?

Saludos,
Tincho.

On Tue, Apr 9, 2013 at 12:55 PM, Manuel Quiñones <manuq at laptop.org> wrote:

> 2013/4/8 Manuel Quiñones <manuq at laptop.org>:
> > 2013/3/28 Daniel Narvaez <dwnarvaez at gmail.com>:
> >> Hi,
> >>
> >> I started experimenting a bit with github code reviews, with Walter as
> >> ginuea pig :) We wasn't too sure about stuff like rebasing, using
> >> separate branches etc, so tonight I played a bit myself with creating
> >> pull requests.
> >>
> >> Something like the following might be a decent start for a workflow
> >>
> >> 1 Create one branch per topic
> >
> > 0. Fork
> >
> > I forgot to do it in my first pull-request submission.
>
> And add a remote for upstream.  Example:
>
> git remote add upstream https://github.com/sugarlabs/sugar.git
>
> Which is useful to keep your fork in sync.  This is for the record, we
> need to write the documentation of the workflow.
>
> >>
> >> git checkout -b topic1
> >>
> >> 2 Make one or more commits
> >> 3 Push the branch
> >>
> >> git push origin topic1
> >>
> >> 4 Submit a pull request for the branch (web UI)
> >>
> >> 5a The reviewer merges the patch.
> >> 5b The reviewer rejects the patch (and closes the request).
> >> 5c The reviewer requires changes (and closes the request).
> >>
> >> If 5c:
> >>
> >> 6 Make changes using interactive rebase
> >> (
> http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages
> )
> >>
> >> git rebase -i master
> >>
> >> 7 Push the changes to another remote branch
> >>
> >> git push origin topic1:topic1-try2
> >>
> >> 8 Submit the new pull request (web UI)
> >>
> >>
> >> If someone has experience with github suggestions would be welcome.
> >> Otherwise I hope Walter will keep being the ginuea pig in this
> >> experiment  :)
> >>
> >> --
> >> Daniel Narvaez
> >> _______________________________________________
> >> Sugar-devel mailing list
> >> Sugar-devel at lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
> >
> > --
> > .. manuq ..
>
>
>
> --
> .. manuq ..
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130409/c88053fe/attachment-0001.html>


More information about the Sugar-devel mailing list