git branches on branches
fw at fwright.net
Thu Jan 19 04:24:51 UTC 2017
On Wed, 18 Jan 2017, Craig Treleaven wrote:
> I’ve proposed a change to the mariadb-server. I created a local git
> branch (“dbinstaller”) while working on it and then posted a patch
> to Trac for the maintainer to review.
> I wanted to go forward and develop/test changes to my mythtv.28 port
> that depend on the mariadb-server changes. I created another local git
> branch from master (dvrinstall) for that work. It only just occurred to
> me that the mariadb-server changes don’t exist in my dvrinstall
> branch. (Duh.)
> How can I incorporate the mariadb-server changes with my mythtv.28
> changes for testing yet, when it comes time to push, only push the
> mythtv.28 commit(s)? Please be really explicit—my git experience fits
> in a thimble with much room to spare!
> More generally, is there a preferred approach that one should follow in
> such cases in the future?
One way to do this sort of thing is to create a test branch with the
merged changes, e.g.:
$ git checkout -b test master
$ git cherry-pick master...dbinstaller
$ git cherry-pick master...dvrinstall
If the patches interact, you might need to do something more complicated,
but the general idea is that you now have a branch with the combined
changes. If you need to fix things, it's probably safest to make the
changes on the appropriate "source" branch(es), and then "rebuild" the
test branch. When you're done, delete the test branch.
If your dvrinstaller branch is just for testing, then of course you can
just use that one and use cherry-pick from dbinstaller to copy the commits
It's also possible to do this in reverse, where you do development on a
single branch, and then when the time comes to push a subset of the
commits, create a new branch and cherry-pick just the appropriate commits
from the development branch (and test the results to the extent possible).
More information about the macports-dev