[Buildbot-devel] github workflow for Buildbot source tree

[Dustin J. Mitchell]

On Wed, Feb 3, 2010 at 10:24 PM, Charles Lepple <clepple at gmail.com> wrote:
> I'm trying out github, and I was going to create a new branch to track
> some changes.

Great!

> However, I "forked" djmitche/buildbot a few days ago, and my changes
> are small enough that, if I were working locally, I would just rebase
> rather than merge. I tried rebasing a doc change onto a later version
> of djmitche/buildbot/master, and GitHub refused my "git push" of my
> branch, since it wasn't a fast-forward. I created a new branch, and
> pushed that, and now I get a 404 for http://github.com/clepple/
> buildbot (I'm hoping that last part was mere coincidence).

Yeah, github is having some hardware problems right now:
  http://twitter.com/github
You don't have push permission to my repository, so you can use push
-f (force) rather indiscriminately, even on master.  However, it is
quite helpful if you push your development to named branches in your
github repo.  That way, if you push several improvements, we don't
have to try to sort out which commits on master represent each
improvement.

> At this point, I'm having a bit of trouble separating what seems to be
> expected behavior with github, versus unexpected behavior due to
> github downtime.

As far as I can tell, the Git interface to github is working fine
right now - just not the web interface.

What usually confuses folks is that there are *three* repositories
involved: mine, your github repo (your "fork"), and your local
repository.

> I re-read http://buildbot.net/trac/wiki/SubmittingPatches and didn't
> see any mention of rebasing. What is the recommended way to keep
> patches based on a current head?

You've basically got it right.  The only concern is that you should
generally try not to rebase things once they've been pushed, and
definitely not after you've sent a pull request for them.  That's what
git is trying to tell you when it can't "fast-forward" a branch.  Some
branches are, in an ad-hoc fashion, often rebased.  For example,
Brian's 'schedulerdb-REBASES' -- and he was helpful enough to include
a warning about that in the branch name.

If I try to pull a change of yours, and it doesn't apply cleanly
against HEAD (and I can't trivially resolve the conflicts), I'll
usually write back to you to ask you to rebase onto my master.  Then
it's OK to rebase, because everyone who might be affected (you and me)
know what's going on.

Git gives you *plenty* of rope to hang yourself with, when it comes to
remote repositories :)

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com