From: Vladimir K. <vka...@op...> - 2013-09-24 19:40:56
|
> I think this is going to be the first time we merge github branches in > SWIG. I don't truly know what we should be doing. What I do know is that > if I was to merge most branches, it completely confuses me with all the > history of the development in the branch tangling the history of master. > So in many ways I'd prefer not to see the history of the development of > any of the branches, rather a single patch to apply to master with 'git > am'. It seems that many projects work this way. A rebase should result > in an easy to read branch history, so I'm all for a rebase too. I > believe the correct etiquette is to create a new branch with the rebase > as the current branch is already public. > > Anyway, if I merge or apply a patch, your branch needs to be in a clean > working state to for merging to current master. Ultimately I would like > a Github pull request. I will then either 'git merge' it or 'git am' it > when the Travis tests all pass. Could you wait until 2.0.11 is released > before doing this though? > I merged the current swig master to my branch, so that now it can be easily merged upstream. Since you are going to ignore the branch history (--squash), doing rebase makes no sense (rebase would only be necessary to get a cleaner version of the branch history). I also posted a pull request on github. |