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 [email protected]: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 <[email protected]> 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 [email protected]
> > 5621 Arapahoe Ave, Suite A Phone: (720) 466-3196
> > Boulder, CO 80303 Fax: (303) 448-7756
> > <git-worktree.rst>
>
--
Scott Kruger
Tech-X Corporation [email protected]
5621 Arapahoe Ave, Suite A Phone: (720) 466-3196
Boulder, CO 80303 Fax: (303) 448-7756
