[OH-Dev] Mid-month check-in: Sat 3/17, 4PM Eastern / 1 PM Pacific

[Daniel Mizyrycki]

On 03/28/2012 08:32 AM, Asheesh Laroia wrote:
> Excerpts from Daniel Mizyrycki's message of Tue Mar 27 21:48:52 -0400 2012:
>> I am replying inline a couple of emails here as they relate.
>>
>> On 03/16/2012 11:24 PM, Pam Selle wrote:
>>>   I want to work on this. Not right now, maybe not till next weekend,
>>>   but I do :)
>> Pam and everybody who'd like to move forward docs: There are a few wiki
>> documents that are already translated to ReST and indexed, so what needs
>> to be done is much easier now. Let's try to coordinate here for an IRC
>> discussion. Who is interested?
> I'd show up (-:
>
> I suggest that you pick one or two times and see who says they can come.
What about Saturday 12:00?    Sunday 11:00?

>   I would say yes, let's move all documentation to docs/, except leave
>   a README.rst that simply says, "For documentation, look in the docs/
>   directory."
Done. Pull requested :)
>>>   I like this idea. I'd say contributors.rst but whatever's most common
>>>   in rST-land.
>> I'll do some surveys on this.
> * Add an authors.rst or/and contributors.rst file on the repo.
> Awesome! Also, feel free to just pick one randomly.
Will do

>
>
>> Nice. I've got an issue though. I forked oh-mainline and before my
>> previous pull
>> request I did "git pull --rebase upstream master" so my commits get
>> added to the end
>> of the history, and keep master history linear. After the pull request
>> got merged, plus some other commits, I tried to  "git pull --rebase
>> upstream master" (this went well) and "git push" (back to my fork and got:
>> To git at github.com:mzdaniel/oh-mainline.git
>>    ! [rejected]        master ->  master (non-fast-forward)
>> error: failed to push some refs to 'git at github.com:mzdaniel/oh-mainline.git'
>>
>> After doing gitk, found that the history of oh-mainline is not linear.
>> Any quick reference to a howto I can look at to push my changes for a
>> proper pull request?
> Once you have rebased your changes to be on top of origin/master , create a
> new branch on your personal github fork, and then use the github.com functionality
> to request your branch be merged into openhatch/oh-mainline:master .
>
> I am not an experienced Github.com users, but I do have experience with Git itself.
>
> Here's what I suggest as a workflow. You've already done much of this, but for new
> people I wanted to lay it all out.
>
> * In Github.com, create a 'fork' of the OpenHatch project
>
> * On your machine, use 'git clone' to clone from that fork. Now 'origin' is your
>    writable Github fork.
>
> * Create a remote called openhatch that points at the official repo
>
>     git remote add openhatch git://github.com/openhatch/oh-mainline.git
>     git fetch openhatch
>
> * On your local machine, make the 'master' branch point to openhatch/oh-mainline:master
>
>     git checkout master
>     git fetch openhatch
>     git rebase openhatch/master
>
> * Periodically, use 'git fetch openhatch&&  git checkout master&&  git rebase openhatch/master'
>    to keep that in sync
>
> * As you work, create local feature branches:
>
>     git checkout openhatch/master -b my_feature_branch
>
> * Make changes, and make local commits
>
> * If you're ready for casual review, just push that branch to your Github account
>
>     git push origin my_feature_branch
>
> * If you're ready for formal review, make sure it's rebased on top of latest
>    openhatch/master and push (maybe requiring --force so take care)
>
>     git fetch openhatch
>     git rebase openhatch/master
>     git push origin my_feature_branch
>     # Note: You might need to do:
>     # git push --force origin my_feature_branch
>     # if the 'git push' complains about the non-fast-forward
>     # that you saw above.
>
> * In Github.com request that openhatch/oh-mainline:master pull from you!
Thank you for explaining it in such detail, Asheesh. Pull Request in 
place for Sphinx indices.

>
>>>   Does that seem like a usable workflow?
>> Yes. You mention creating a docs branch at some point. Do you still
>> think is a good idea?
>> If yes, I am assuming that branch will be created in my fork and
>> somebody will merge
>> it to master. Then, I just need to rebase my fork and recreate the doc
>> branch for new
>> changes.
> Yup, precisely. See above, and I+others can also help out more on IRC or the
> list.
>
> In your case, you need to just make sure that you do a force push before you
> use the Github.com interface to do the pull request.
I will take a closer look at the docs we have for git and workflow. I 
feel the procedure you explained here deserves to be in the docs. 
Perhaps we can update some of the information to reflect how a typical 
git workflow is done these days.

> -- Asheesh.
> _______________________________________________
> Devel mailing list
> Devel at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/devel
>