git branches on branches

[Fred Wright]

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
over.

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).

Fred Wright