But often one may have the two (or more branches already) and even started MR on them so just using a single branch and splitting it appropriately after the fact might not work. Plus who has the patience to label each commit properly into which MR it will belong when they make each commit and not make a bad commit that includes code that belongs in multiple MR branches.
I am trying Jed's approach. My sanity is nearly gone. > On Apr 18, 2021, at 11:56 AM, Satish Balay <[email protected]> wrote: > > On Sat, 17 Apr 2021, Barry Smith 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). > > The primary issue is managing the dependencies between changes (commits, > features). And when making a new change - (for each new change) evaluate and > update, reorder the prior commits as needed. > > Attempting to avoid this usually results in a bad commit history - and I've > been trying to avoid in petsc history. [currently a single merge commit - > which is not cohesive - or easily debuggable is what I'm falling back on] > > Any work-flow below won't be able to mask the above problem easily. > > If the above problem is managed (requires constant > rebasing/collapsing/rerordering/moving-commits etc] - then the workflow below > is just book-keeping.. [one can aswell use a single branch and split into 2 > branches when the features are complete] > > Satish > > >> 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 >> >
