[Buildbot-devel] github workflow for Buildbot source tree
Dustin J. Mitchell
dustin at zmanda.com
Thu Feb 4 05:25:17 UTC 2010
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.
> 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:
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
> 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
> 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 :)
Open Source Storage Engineer
More information about the devel