[petsc-dev] git worktree

Scott Kruger kruger at txcorp.com
Tue May 18 22:54:28 CDT 2021

Ahhhh.  I remember your email about it, and I even have it checked out.
I didn't get it at the time, but necessity is not only them other of
invention, but of learning.


On 2021-05-18 18:39, Barry Smith did write:
>   Scott,
>     My solution to working with multiple PETSc branches without the agonizing pain is git at 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 <kruger at 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               kruger at txcorp.com
> > 5621 Arapahoe Ave, Suite A       Phone: (720) 466-3196
> > Boulder, CO 80303                Fax:   (303) 448-7756
> > <git-worktree.rst>

Scott Kruger
Tech-X Corporation               kruger at txcorp.com
5621 Arapahoe Ave, Suite A       Phone: (720) 466-3196
Boulder, CO 80303                Fax:   (303) 448-7756

More information about the petsc-dev mailing list