[petsc-dev] git worktree

[Patrick Sanan]

Cool - I didn't know about this approach - If you still have your experiments sitting around, can you put numbers on what kind of space savings are we talking about vs the dumb approach (I have an independent clone for every branch I'm interested in working on simultaneously)?

@Barry - thanks for the reminder about that script - even if I don't use it regularly it's good to know it's there to raid in the future when I'm pushed in desperation to start scripting things. 

Re the related shallow/"blobless" clone stuff I was posting about [1] - it's fun and work-adjacent (hence in #random) to read about and good to be able to pull out of your pocket when some pathological repo comes along, but the boring truth is that because it's another syntax to remember (or script) and there's a minor inconvenience in the usage (I don't like the way it behaves when you need to fetch something missing, and there's no internet connection), I'll likely never use the feature in my normal workflow. The robustness, simplicity, and google-ability of the dumb way are too attractive!


[1] https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ <https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/> 


> Am 19.05.2021 um 05:54 schrieb Scott Kruger <kruger at txcorp.com>:
> 
> 
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20210519/48892938/attachment.html>