I maintain a git fork of bitlbee, which I use since bzr sucks. But submitting stuff upstream requires creating bzr branches.
There is an ongoing, very slow, and not particularly aggressive effort to get rid of that 'requirement' - here's my weird-ass workaround, meanwhile.
I've been keeping my git/bzr workflow notes in the bitlbee-dx readme, but they don't really belong there. Also, the commit history is already quite messy, I'd rather not make it worse with a bunch of README changes.
WIP - just copied the readme directly from the repo for now, needs some updating
master: follows upstream (was using
upstreamfor this before)
develop: main bitlbee-dx branch.
patch/*: small patches and bugfixes (may be stolen from trac)
feat/*: non-trivial features
<username>/*: git mirrored branches of other people (like
wip/*: incomplete stuff.
This is a fork in the sense of a standalone project, but i'm also intending to merge as much as possible upstream. Unfortunately upstream uses bzr, and bzr is awful. Thanks to git-remote-bzr, most of this pain is avoided, but I've had to do some compromises to keep this workflow.
Simple stuff first: features belong in feature branches, pull requests are used for the review process. Travis-ci integration is enabled, but the test suite isn't extremely comprehensive.
The develop branch diverges from master. Use
git cherry -v master to compare
them. Commits that are in both branches are prefixed with a
- (even if they
have different commit objects), while commits unique to develop are prefixed
git checkout -b branch-for-upstream master # cherry pick relevant commits, or fast-forward feature branches git cherry-pick CAFEBABE # TODO: figure out how to create a new remote bzr branch. i always forget # let git-remote-bzr know this branch exists git config remote.bzr-dequis.bzr-branches "upstream, branch-for-upstream" # push to bzr.dequis.org git push bzr-dequis branch-for-upstream
A fast forward is required so that
bzr pull works, otherwise
should be run, which generates a fat merge commit hiding all the commits in a
sub-timeline. Weird stuff.
Merging back from upstream:
git fetch bzr-bitlbee git checkout master git merge bzr-bitlbee/master # fast-forward
Then the commits from master are rebased to develop.
git checkout -b master-rebase git rebase develop git checkout develop git merge master-rebase # fast-forward git branch -d master-rebase
And this is why i say they diverge - all the commit objects are different. I reserve the right of rebasing develop to clean up this mess to match upstream at some point.
To handle .bzrignore as .gitignore in the bzr-only branches (which don't have git specific stuff since they need to be sync'd perfectly with upstream)
git config core.excludesfile .bzrignore