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

[Matthew Knepley]

On Sat, Apr 17, 2021 at 7:38 PM Jed Brown <jed at jedbrown.org> wrote:

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

This is what happens for PyLith. I work on a few topic branches that are
all needed. I keep a branch, knepley/pylith, to hold all of this. In my
work branches,
I just pile the commits in until everything is working. That way merges are
knepley/pylith are fast-forward. Then when these branches pass the CI and
are
ready to be merged to PETSc, I rebase them and make nice commits, then
recreate knepley/pylith. That means everyone else in the project has to
destroy
the old knepley/pylith and get a new one, which is annoying, but I do not
see a better way.

It might be nice if git had an ephemeral branch feature, where you could
say that some branch is the combination of a few others and every
time they change, it changes too.

  Thanks,

     Matt


> 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 <bsmith at petsc.dev> 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
>
>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20210418/2aadadf4/attachment-0001.html>