[Sugar-devel] Managing github forks

[Will Orr]

Hello, 

When doing work on my feature branch, usually I do a git pull --rebase origin master to update, that way my patches will cleanly apply to the master branch of the project when I file my pull request. I avoid merge commits this way as well. 

The downside is that I might be messing with the history of my feature branch, which might even be public. 

William Orr 

Manuel Quiñones <manuq at laptop.org> wrote:

>2013/5/26 Daniel Narvaez <dwnarvaez at gmail.com>:
>> Hello,
>>
>> I've been playing with a slightly different workflow with github
>> repositories and it seems to work well for me.
>>
>> I keep origin to be git at github.com/sugarlabs/module and I add a fork remote
>> pointing to git at github.com/dnarvaez/module.
>>
>> To send pull requests I just
>>
>> git push fork myfeature
>>
>> To merge other people patches
>>
>> git checkout master
>> git pull git://github.com/theirname/module theirfeature
>> git push
>>
>> To update the fork (but with setup it doesn't even seem to be quite
>> necessary, you could just stay on origin master and only worry about fork
>> branches).
>>
>> git pull
>> git push fork master
>>
>> This seems to be working pretty well for me so far. Thoughts?
>> If it works well for people in general I could add prefs to sugar-build to
>> set this up automatically. It's pretty annoying to have to setup the remote
>> configuration every time you do a clean clone.
>
>Yes, this works well but you should be more careful whlie hacking,
>because a wrong push could mess the main repository (calling commands
>in the wrong order, for example).  Personally I hack in my own fork,
>and when I put my reviewer hat I switch to the main repository
>directory.
>
>By the way as this works for you and there are optional preferencies, I'm +1 .
>
>--
>.. manuq ..
>_______________________________________________
>Sugar-devel mailing list
>Sugar-devel at lists.sugarlabs.org
>http://lists.sugarlabs.org/listinfo/sugar-devel