One option is to work on the throw-away combined branch as above, keep your commits for the two topics distinct, then cherry-pick out into the separate topic branches. If you are committing in the topics and respinning the throw-away branch, I would recommend rerere, so you don't have to repeat conflict resolution. https://git-scm.com/docs/git-rerere On Sat, Apr 17, 2021, at 5:02 PM, Jacob Faibussowitsch wrote:

I have done this maybe only a handful of times (and not with petsc) but take a look at git worktree https://git-scm.com/docs/git-worktree

The basics of it is:

1. cd $PETSC_DIR — or wherever the root folder of your repo of choice is 2. git worktree add ../myBranchName

Then this recreates the entire src tree of the current branch in a separate directory (namely $PETSC_DIR/../myBranchName). Not sure how useful it is for petsc, given how dependent everything is on $PETSC_DIR but it's occasionally useful. Its as if you had 2 separate clones of petsc, but they both share the same .git folder (I think).

Best regards,

Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch)

...

On Apr 17, 2021, at 17:24, Barry Smith <[email protected]> wrote:

Say I have a project (a code whose source is not in the PETSc repository) that requires code from two PETSc branches (that may or may not yet be MR) but I do not want to make a single PETSc branch (since it would be incoherent). I may possibly be needing to add code to both of the PETSc branches as I develop the project. I also need to do development sometimes on different machines.

I can do

git checkout branch1 git checkout -b combinedbranch git merge branch2 configure make use for a while

but now I need to fix or add something to branch1 (which, of course, will be an iterative process as I write the code and fix it) and then add something in branch2.

Doing the above procedure over and over again is tedious and prone to produce errors, editing in the wrong branch etc.

Does anyone have advice on good work flows for this situation?

Barry