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 >
