Contributing using git and github

477 views
Skip to first unread message

Iain Wood

unread,
Feb 9, 2012, 5:07:19 AM2/9/12
to over...@googlegroups.com
I sent a pull request on some code I thought might be a useful addition to overtone, however I think I made a mistake. What I think I should have done is create a branch in my own repo (soulflyer/overtone) and push from there. What I did was use soulflyer/overtone/master and send the pull request from there..

Now I want to work on something else, but I have changes in my master branch that I don't want to appear in another pull request.

Is there an easy way to tidy this up? If I was to delete the lot and start again that would make things all neat and tidy again but I would rather not change history and I don't know if it would cause problems with the pending pull request...

Any git experts care to comment?

Iain

Mat Schaffer

unread,
Feb 9, 2012, 8:17:06 AM2/9/12
to over...@googlegroups.com
Feature branches help this situation. If you want to avoid altering history, the simplest thing may be to make a new feature branch from origin/master and work there for awhile. Just don't merge back to master until your pull request has been merged (since anything new on master will get appended to your pull request). Like so:

git checkout origin/master
git checkout -b new-feature

Another way that would change history but get you back to a more standard state (where your master matches overtone/master) would be:

git checkout master
git checkout -b my_feature_branch
git push -u origin my_feature_branch
git checkout master
git reset --hard origin/master
git push --force origin master

As far as I can tell, you can't update the branch of the current pull request though. You'd have to close it and open a new one if you went this route.

Let me know if you have an questions.
-Mat

Mat Schaffer

unread,
Feb 9, 2012, 8:22:39 AM2/9/12
to over...@googlegroups.com
Whoops, just realize'd a correction, see below:

On Thu, Feb 9, 2012 at 8:17 AM, Mat Schaffer <m...@schaffer.me> wrote:
Feature branches help this situation. If you want to avoid altering history, the simplest thing may be to make a new feature branch from origin/master and work there for awhile. Just don't merge back to master until your pull request has been merged (since anything new on master will get appended to your pull request). Like so:

 
The next line should probably be overtone/master since origin is probably your fork and you want to get back to overtone's master. 

Iain Wood

unread,
Feb 9, 2012, 2:17:40 PM2/9/12
to over...@googlegroups.com
Thanks for that Matt, that was a big help. I have upstream pointing to overtone/overtone so with these small mods I get the desired results:

>
> git checkout origin/master
git checkout upstream/master


> git checkout -b new-feature
>
> Another way that would change history but get you back to a more standard state (where your master matches overtone/master) would be:
>
> git checkout master
> git checkout -b my_feature_branch
> git push -u origin my_feature_branch
> git checkout master
> git reset --hard origin/master

git reset --hard upstream/master


> git push --force origin master
>

I went for the second one, and re-issued the pull request. I now have a nice clean master copy, a branch with my current code in, a branch for my new code, and a small clue how to use git more effectively :-)

Iain

Reply all
Reply to author
Forward
0 new messages