Merging a long-active development branch of a package

Those who follow the JuliaStats world will be aware that a major upgrade of StatsModels just landed as v"0.6.0", aka “Terms 2.0”. Thanks to @dave.f.kleinschmidt for leading the development on this.

I have a “terms2.0” branch in the MixedModels package repository that uses this new formulation, which I would like to incorporate into the “master” branch. The development branch is about 150 commits ahead and 20 commits behind master.

What is a good strategy to merge such a development branch into the master branch?

Should I try to rebase terms2.0 on master first? Some things get a bit tricky there because both branches switched from REQUIRE to Project.toml so there are commits that change a REQUIRE file that is no longer part of the project.

I know that at some point I want to collapse all the changes in the terms2.0 branch to a single commit on the master branch, as @dave.f.kleinschmidt did in StatsModels. I just not sure exactly when that is done.

1 Like

Rebases like this can get annoying pretty quickly. There are tools that can make it easier but if you’re going to produce a single commit in the end it’s probably not worth the pain. The easiest way to get that commit is to merge master into your branch and then when everything is in the state you want to end up in, just take that working tree and make a commit out of it on top of master. One way to do this is from the tree you want to commit, check out master without checking out the files (I forget the invocation), then just make the commit. This is way easier than screwing around with rebasing in my experience.

2 Likes

Another way to do it is to get in the state you want things in with whatever history, do git diff master > patch.diff to save the diff from master to a file, then check out master and do git apply < patch.diff To apply that diff on top of master. Poof, history gone!

Then when you commit it, you may want to change the lead author and/or add co-authors to respect the authorship of the branch. You can change the lead author with the --author git switch, and you can add co-authors by putting Co-authored-by: ... lines at the bottom of your commit message.

2 Likes

While you can do the manual process suggested above, I wouldn’t recommend it. Instead, you can just ask github to do the work of taking your branch and converting it into a single commit onto master by doing a squash-merge, which is available any time a github pull request is merged (see https://help.github.com/en/articles/about-pull-request-merges#squash-and-merge-your-pull-request-commits ).

My recommendation would be:

  1. Merge master into your branch on your machine
  2. Push your updated branch
  3. When your PR is ready to go, make sure whoever merges it uses the “squash and merge” option.

No rebasing or manual patch creation necessary :slightly_smiling_face:

4 Likes

Thank you for the responses. I ended up using @rdeits suggestions and it worked smoothly, I think. Of course, past experience with git makes me cautious about any “it worked smoothly” claims.

3 Likes