[petsc-dev] how do people manage projects that require two or more PETSc branches

[Barry Smith]

  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 <balay at mcs.anl.gov> 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
>> 
>