[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.
Scott
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