← Back to team overview

openstack team mailing list archive

Re: Forking an OpenStack project to remotely save changes

 

On Tue, 2012-06-05 at 14:43 -0600, Everett Toews wrote:
> Hi All,
> 
> If you have a relatively long-lived topic branch, what's the best way to
> remotely save changes?
> 
> If you wanted to fork an OpenStack project on github, it would work
> something like:
> 
> 1. Fork the project on github.com to your own account
> 2. Clone the project locally
> 3. Add a remote branch to your local repo that points to the origin project
> repo you forked from
> 4. Create a remote branch for gerrit
> 5. Create a branch for your changes in the forked project
> 6. Commit and push your changes to your branch
> 7. When your branch is ready for review:
> a. pull from origin
> b. rebase your changes to the current state of the master
> 8. git review
> 
> I've done steps 1-6 working but I can't easily test 7 & 8 without sending
> in unnecessary changes for review. But if you lost your changes, you would
> just clone your forked project again.

What I do is:

  1) Clone from github.com/openstack/${project}

  2) Click "fork" on $project on github

  3) Add my fork as a remote to my local repo:

       $> git remote add -f github git@xxxxxxxxxx:markmc/${project}.git

  4) Create my topic branch, hack commit my changes

  5) Push to my forked repo:

       $> git push github HEAD:${topic}

  5) Hack, commit more changes, then clean up the series of patches 
     using 'rebase -i'

       $> git rebase -i origin/master

     this might involve rebasing onto latest upstream, squashing fixes
     into an earlier patch, re-ordering changes, editing commit messages

  6) Push to my forked repo either as a new branch if I worry that 
     others might have based their work on my first branch:

       $> git push github HEAD:${topic}-v2

     or, more usually, just push to the same branch:

       $> git push github +HEAD:${topic}

     (the '+' allows me to do a non-fast-forward push)

  7) When I'm done, submit it with git-review


I'm guessing the details of (5) and (6) is what you're missing?

Cheers,
Mark.



Follow ups

References