Scott,
My solution to working with multiple PETSc branches without the agonizing pain is g...@gitlab.com:petsc/petscgitbash.git One could argue it is too particular to Barry's specific workflow but perhaps it has ideas/code that can be stolen for others. It could also potentially be done using the gitlab python bindings and thus remove the direct use of the rest full interface. I have been using it for about a year and a half and probably for about six months it has been pretty robust and stable. A reminder of its approach # An alias for git that manages working with multiple branches of PETSc from the command line # This is specific to PETSc and not useful for any other respositories # # Replaces some actions that normally require cut-and-paste and/or (manually) opening the browser to gitlab.com # # + Sets the PETSC_ARCH based on the branch name # + Preserves compiled code associated with the branch checked out when changing branches # + Updates lib/petsc/conf/petscvariables with the branch values so, for example, you can compile in Emacs without knowing the PETSC_ARCH in Emacs # + Creates new branches with the name ${PETSC_GIT_BRANCH_PREFIX}/DATE/yourspecificbranchname # + Adds /release to branch name if created from release branch # + Can checkout branches based on a partial branch name, if multiple branches contain the string it lists the possibilites # + Submits branches to pipeline testing from the command line # + Checks the current branches latest pipeline test results (and optionally opens the browser to the pipeline) # + Opens new or current MR without cut and paste from the branches # # Oana suggested the idea to save waiting for code to recompile after changing branches and the use of touch # to force code to not get recompiled unnecessarily. This inspired this script which then grew uncontrollably. # # Does NOT change the source code in any way, only touches the object files # # Does not currently have a mechanism for multiple PETSC_ARCH for a single branch # # Requires git higher than 1.8 TODO: add a check for this # # Usage: # git checkout partialname # git checkout - check out the last branch you were on # git checkout -b newbranchname [rootbranch] [message] adds ${PETSC_GIT_BRANCH_PREFIX}, date, and /release (when needed) to new base branch name # The message can contain what the branch is for and who inspired it # git checkout -b newbranchname [main or release] # git pl [partialname] run a GitLab pipeline # git cpl [-show] [partialname] check on status of pipeline # git mr [-f] [partialname] open new or current MR for current branch, -f allows MR without first submitting pipeline # git branch -D[D] [partialname] deletes branch you may be currently in, extra D deletes remote also # git rebase [partialname] pulls main or release as appropriate and then rebases against it # git branches lists branches in MR, in MR as WIP, tested but not in MR and not merged in main with pipeline results # git push [-f] [partialname] pushes branch # git fixup commit changes and rebase as fixup in the current branch and force push resul # git mrfixup rebases branch as fixup to remove all commits applied by MR with Apply suggestion # git cherry newbranchname [release] removes the most recent commit from the current branch and puts it in a new branch off of main [or release] # git pop go to previous branch, before git checkout (like - except handles multiple branch changes in the script) # git diff do git diff HEAD~1 # # cizappipeline delete all the blocked/manual MR pipelines (appears to only work for project owners? # cibuild url [-show] login into the test machine and build the PETSc version being tested # > On May 18, 2021, at 5:40 PM, Scott Kruger <kru...@txcorp.com> wrote: > > > > Relatively recently, I learned about the git worktree feature and > attached my write-up of how I use it in petsc. I have no idea whether > the response will be: > > This has been around since 2015 at least, and you're just now > finding out about it? LOL! > > or: > > I can't believe I never heard about it either! > > > Since Patrick recently talked about shallow clones with git on slack, I > suspect it's the latter (and I didn't hear about this feature from petsc > dev's which is where I typically gain all my git knowledge). Basically, > if you have more than one clone of petsc on your drive, you'll be > interested in the worktree feature. > > The reason why the write-up is a bit long boils down the fact that we > have the `/` in our branch names. It makes things a bit more > complicated compared to my other projects (but is nice for the directory > structure). I have not scripted away the complexity either -- I haven't > reached that level of annoyance. > > The reason why I just don't have the rst file as an MR, is because the > way I have it point to an existing branch seems cumbersome. Perhaps a > git guru knows an easier way with some type of detached state or faster > way of getting the HEAD to point to the right sha in one go. I'd be > very interested if someone knows a better method. > > Scott > > > -- > Scott Kruger > Tech-X Corporation kru...@txcorp.com > 5621 Arapahoe Ave, Suite A Phone: (720) 466-3196 > Boulder, CO 80303 Fax: (303) 448-7756 > <git-worktree.rst>