Branching/rebasing policy

[tkelman]

Upstream (from the git mirror) has branches called 2.7, 3.4, master, etc. This is a fork, so has to pull new commits from the git mirror every so often (we should write a cron script to automate this). We shouldn't commit to those branches so they stay pristine from upstream, and all pulls are fast-forwards.

Make new branch for each rebase? Maybe called 2.7_rebase141028, master_rebase141028, etc? Also named topic branches for work on each PR to bring patches in. JuliaLang informally has topic branches start with person's initials, easier to group them together that way.

[mingwandroid]

Sounds good. I was going to ask about github automation for pulls .. is there any way? I would have expected there's something, but maybe not.

At each rebase of master, can we remember to set that as the default branch? Also, is it easy to get the sha1 to create a branch from at each tarball release, as for MSYS2's PKGBUILDs we'd probably like to build from those branches (onto which we would cherry-pick the rebased patches from the respective 2.7_rebase / 3.x_rebase branches I assume?)

[tkelman]

I synced manually about half an hour ago, it looked like this

git clone https://tkelman@github.com/cross-python/cpython # this fork
cd cpython
git remote add upstream https://github.com/python/cpython # the automatic mirror
git fetch upstream
git checkout -t origin/3.4 # this fork's version of 3.4
git pull upstream 3.4 # fast-forward pull upstream mirror into local 3.4 branch
git push origin 3.4 # fast-forward push local 3.4 branch to this fork

and similar for other branches, but don't need -t if the local branch already exists. I think we can script that no problem. Replace the clone/remote with your favorite protocol or method of authentication.

At each rebase of master, can we remember to set that as the default branch?

This may end up being a pain to remember, let's see. We could handling syncing with upstream as merges, but that would mean any conflict resolution gets interleaved with our work commits, and the patches don't apply cleanly. To rebase means we need to resolve the conflict at the original patch level, so we fix them to apply cleanly to the updated codebase. But it involves either creating a new branch each time, or force pushing and rewriting history which is not a good idea to do too often on important branches.

We'll see how often rebases are required. Weekly? Monthly? Dunno. If conflicts arise, the person doing the rebasing might not know how to fix them and we'll have to open an issue to come up with the best way to resolve the rebase conflict.

Also, is it easy to get the sha1 to create a branch from at each tarball release

Very. https://github.com/cross-python/cpython/archive/124be47309b3649388d9f14b1b1593ce8ab0f3ca.tar.gz

Or make a tag if you want something more permanent.

edit: ignore that, I misunderstood what you were asking