Closed weberc2 closed 10 years ago
I can add the binding. Is it just the one function that needs merging?
Btw, the reason it's trying to merge more in is because we try to keep our master branch as clean as possible (avoiding merge commits, squashing and rebasing before doing a ff-only merge). I actually can't push a merge commit to our actual git repo (github is just a mirror). Git isn't designed for this workflow and can't figure out what has and hasn't been merged in already because of the history loss. I hate it but they pay me so hey...
Looks like it. Cherrypicking it now...
Gotcha. If you're sufficiently annoyed by cherrypicking, maybe you could write up a 'workflow' wiki page? I'm happy to oblige, I just struggle a lot with git(hub) and consequently need step-by-step instructions. I would appreciate the learning opportunity, but it's your call.
Cherrypicking isn't hard and it's one of the few things git is very good at.
Really, there isn't any good solution. The "right" way to play along with our dev model is to develop extra features on feature branches, keep your master in sync with upstream, and squash+rebase feature branches against your master. When those features are ready, they get sent off to us as pull requests. The problem with this though is that I can tell you're implementing features on master because you're actually using them, and writing them on feature branches will break go get for other projects using the code.
I don't understand why, but the "files changed" for this pull request is showing every change I've made since I forked your repository, even the ones that have already been integrated into the main fork. Hopefully on your end you're able to just see the actual diff between our two branches. If not, please feel encouraged to advise this mere mortal on the correct Github pull request procedure, because the Github docs and so many Google searches have failed to instruct me.