[petsc-dev] git worktree

[Barry Smith]

  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>