[Sugar-devel] Managing github forks

[Manuel Quiñones]

2013/5/29 William Orr <will at worrbase.com>:
> Why not rebase to update? The current guide can lead to some messy merge
> commits.

I don't know Will.  Maybe you are right.  What we do is the
recommended way in github:

https://help.github.com/articles/fork-a-repo#step-3-configure-remotes

I don't think you can mess your repository if you always work in a new
branch for each task you do, so your master branch will always be the
same as the sugarlabs repo master branch.

http://developer.sugarlabs.org/contributing.md.html#sending%20a%20pull-request

But I'm happy to discuss improvements.

> I guess you can fix it with an interactive rebase later, but this has always
> been the cleanest way I've found to keep my forks up to date as well as
> enabling clean merges of my forks.
>
>> Manuel Quiñones <mailto:manuq at laptop.org>
>> May 27, 2013 9:34 PM
>> Hey William,
>>
>>
>> What I do to keep my forked repo updated is:
>>
>> 1. add a remote to the main repository, call it "upstream"
>> 2. keep in sync with it, fetching and merging often
>>
>> it is explained in our docs:
>>
>> http://developer.sugarlabs.org/contributing.md.html#forking
>>
>> http://developer.sugarlabs.org/contributing.md.html#keep%20your%20fork%20up%20to%20date
>>
>> --
>> .. manuq ..
>> Will Orr <mailto:will at worrbase.com>
>> May 27, 2013 8:59 PM
>>
>> 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
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel



--
.. manuq ..