<div dir="ltr"><div dir="ltr">On Sat, Apr 17, 2021 at 7:38 PM Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div><a href="https://git-scm.com/docs/git-rerere" target="_blank">https://git-scm.com/docs/git-rerere</a></div></div></blockquote><div><br></div><div>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,</div><div>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</div><div>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</div><div>the old knepley/pylith and get a new one, which is annoying, but I do not see a better way.</div><div><br></div><div>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</div><div>time they change, it changes too.</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>On Sat, Apr 17, 2021, at 5:02 PM, Jacob Faibussowitsch wrote:<br></div><blockquote type="cite" id="gmail-m_-5167579937966519744qt"><div>I have done this maybe only a handful of times (and not with petsc) but take a look at git worktree <a href="https://git-scm.com/docs/git-worktree" target="_blank">https://git-scm.com/docs/git-worktree</a><br></div><div><br></div><div>The basics of it is:<br></div><div><br></div><div>1. cd $PETSC_DIR — or wherever the root folder of your repo of choice is<br></div><div>2. git worktree add ../myBranchName<br></div><div><br></div><div>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).<br></div><div><br></div><div><div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-line:none;text-decoration-style:initial;text-decoration-color:initial"><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-line:none;text-decoration-style:initial;text-decoration-color:initial"><div><div>Best regards,<br></div><div><br></div><div>Jacob Faibussowitsch<br></div><div>(Jacob Fai - booss - oh - vitch)<br></div></div></div></div></div><div><div><br></div><blockquote type="cite"><div>On Apr 17, 2021, at 17:24, Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank">bsmith@petsc.dev</a>> wrote:<br></div><div><br></div><div><div><div><br></div><div>  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.<br></div><div><br></div><div>   I can do <br></div><div><br></div><div>      git checkout branch1<br></div><div>      git checkout -b combinedbranch<br></div><div>      git merge branch2 <br></div><div>      configure<br></div><div>      make<br></div><div>      use for a while<br></div><div><br></div><div>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. <br></div><div><br></div><div>Doing the above procedure over and over again is tedious and prone to produce errors, editing in the wrong branch etc.<br></div><div><br></div><div>Does anyone have advice on good work flows for this situation?<br></div><div><br></div><div>Barry<br></div></div></div></blockquote></div></div></blockquote></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>