May 2021 - petsc-dev - mailman3.cels.anl.gov

links from manual pages to users manual
by Barry Smith 25 May '21

25 May '21

Now that the users manual is html and we can properly link into it, it would be great to have links from the manual pages to appropriate locations in the users manual. For example SNESSetFunction.html would have a link to the generated Spinx location where SNESSetFunction is discussed. How do we go about doing this? Not only is this useful for users but when developers are fixing/improving a manual page it would be nice if they had a way to jump directly to the appropriate place in the xxx.rst that that discusses the manual page to check that that material is also up-to-date and correct. So I guess we need a way to link to the correct place in the .rst and the generated .html Thanks Barry In the old users manual I had it rigged to have a link to the manual page for every occurrence of a word that had a manual page in the users manual. Is that feature lost now? Is there anyway to bring it back?

1 0

Re: [petsc-dev] Mat test ex238
by Barry Smith 21 May '21

21 May '21

Ready for approvals https://gitlab.com/petsc/petsc/-/merge_requests/4010 > On May 19, 2021, at 6:19 AM, Stefano Zampini <stefano.zampini(a)gmail.com> wrote: > > +1 > The help says for timing tests, but it makes no sense to me for them being part of the entire CI > We should probably have a dedicated runner for performance regressions (running only performance runs, something like requires: performance) > Not sure why the sizes are so large, probably Barry wants to check for overflows somewhere? > > > > Il giorno mer 19 mag 2021 alle ore 14:12 Matthew Knepley <knepley(a)gmail.com <mailto:[email protected]>> ha scritto: > This is taking hundreds of seconds in every run. For the CI, shouldn't we reduce the size of the matrix, maybe to 5000 instead of 50000? > > Thanks, > > Matt > > -- > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/> > > > -- > Stefano

1 0

Re: [petsc-dev] git worktree
by Scott Kruger 19 May '21

19 May '21

On 2021-05-19 08:36, Patrick Sanan did write: > 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)? The basic difference is in the `.git` directory. Currently a full clone of petsc has a >300MB .git directory for a ~125MB source directory, while a worktree has a <1MB .git file. Even smaller than the light weight clone (by a negligible amount). The ability to have `git branch` show not only all of your local branches but which ones are in a separate directory likely seems like a mild difference, but I find it the main feature I like as it helps remind me of what I have no matter what directory I'm working in. Scott P.S. While looking at what was taking up space in the source tree, it seems like we could save around 10% just by deleting the .eps files in the tau documentation images directory. > > @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-shall… <https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shall…> > > > > Am 19.05.2021 um 05:54 schrieb Scott Kruger <kruger(a)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 [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 <kruger(a)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(a)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(a)txcorp.com > > 5621 Arapahoe Ave, Suite A Phone: (720) 466-3196 > > Boulder, CO 80303 Fax: (303) 448-7756 > -- Scott Kruger Tech-X Corporation kruger(a)txcorp.com 5621 Arapahoe Ave, Suite A Phone: (720) 466-3196 Boulder, CO 80303 Fax: (303) 448-7756

1 0

Re: [petsc-dev] git worktree
by Barry Smith 19 May '21

19 May '21

Lawrence, Oh, I always use that, (even now) my prompt is miles long. Didn't help me at all, I still messed up constantly; my brain ignores what my eyes clearly see. I need more than a clear sign post telling me where I am, I need a hammer that hits me whenever I do something wrong in the terminal :-). Barry > On May 19, 2021, at 9:46 AM, Lawrence Mitchell <wence(a)gmx.li> wrote: > > > >> On 19 May 2021, at 15:38, Barry Smith <bsmith(a)petsc.dev> wrote: >> >> I tried the multiple clone approach first but found I was constantly thinking I was in a different branch than I was in as I went between clones and messing up my working directory and getting confused and frustrated. So I developed some of my tools because I was unable to utilize my brain and working memory to work essentially at all with a multi-clone environment. If one can handle a multi-clone environment then parts of my tools are not needed. > > FWIW, and this may be useful anyway, I use the prompt stuff shipped with git https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh > > so that I know what branch I'm on and if the working directory is dirty etc... > > I too can't remember anything... > > Lawrence

1 0

Re: [petsc-dev] git worktree
by Lawrence Mitchell 19 May '21

19 May '21

> On 19 May 2021, at 15:38, Barry Smith <bsmith(a)petsc.dev> wrote: > > I tried the multiple clone approach first but found I was constantly thinking I was in a different branch than I was in as I went between clones and messing up my working directory and getting confused and frustrated. So I developed some of my tools because I was unable to utilize my brain and working memory to work essentially at all with a multi-clone environment. If one can handle a multi-clone environment then parts of my tools are not needed. FWIW, and this may be useful anyway, I use the prompt stuff shipped with git https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh so that I know what branch I'm on and if the working directory is dirty etc... I too can't remember anything... Lawrence

1 0

Re: [petsc-dev] Mat test ex238
by Barry Smith 19 May '21

19 May '21

I will submit an MR to reduce the CI time, sorry about this. I'm not sure why I ended up with such a big CI test case, probably just sloppiness. > On May 19, 2021, at 6:11 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > > This is taking hundreds of seconds in every run. For the CI, shouldn't we reduce the size of the matrix, maybe to 5000 instead of 50000? > > Thanks, > > Matt > > -- > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0

Re: [petsc-dev] git worktree
by Barry Smith 19 May '21

19 May '21

I tried the multiple clone approach first but found I was constantly thinking I was in a different branch than I was in as I went between clones and messing up my working directory and getting confused and frustrated. So I developed some of my tools because I was unable to utilize my brain and working memory to work essentially at all with a multi-clone environment. If one can handle a multi-clone environment then parts of my tools are not needed. Scripts like "git mr" that open an MR (new or already existing) to the branch I am currently in in my terminal window save me having to hunt around with the browser. It also correctly selects either release or main to merge into which saves me endless time since I would always forget when doing everything from the GUI to set release branches to merge off release. Anyone can adopt this script.I had similar things for managing the non-MR pipelines but since no one uses that approach any more they are not useful, I need to update them for MR pipelines. Barry > On May 19, 2021, at 1:36 AM, Patrick Sanan <patrick.sanan(a)gmail.com> wrote: > > 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-shall… <https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shall…> > > >> Am 19.05.2021 um 05:54 schrieb Scott Kruger <kruger(a)txcorp.com <mailto:[email protected]>>: >> >> >> >> 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(a)gitlab.com <mailto:[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 <http://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(a)txcorp.com <mailto:[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 kruger(a)txcorp.com <mailto:[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 kruger(a)txcorp.com <mailto:[email protected]> >> 5621 Arapahoe Ave, Suite A Phone: (720) 466-3196 >> Boulder, CO 80303 Fax: (303) 448-7756 >

1 0

Re: [petsc-dev] Mat test ex238
by Stefano Zampini 19 May '21

19 May '21

+1 The help says for timing tests, but it makes no sense to me for them being part of the entire CI We should probably have a dedicated runner for performance regressions (running only performance runs, something like requires: performance) Not sure why the sizes are so large, probably Barry wants to check for overflows somewhere? Il giorno mer 19 mag 2021 alle ore 14:12 Matthew Knepley <knepley(a)gmail.com> ha scritto: > This is taking hundreds of seconds in every run. For the CI, shouldn't we > reduce the size of the matrix, maybe to 5000 instead of 50000? > > Thanks, > > Matt > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/ > <http://www.cse.buffalo.edu/~knepley/> > -- Stefano

1 0

Mat test ex238
by Matthew Knepley 19 May '21

19 May '21

This is taking hundreds of seconds in every run. For the CI, shouldn't we reduce the size of the matrix, maybe to 5000 instead of 50000? Thanks, Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0

Re: [petsc-dev] git worktree
by Patrick Sanan 19 May '21

19 May '21

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-shall… <https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shall…> > Am 19.05.2021 um 05:54 schrieb Scott Kruger <kruger(a)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 [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 <kruger(a)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(a)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(a)txcorp.com > 5621 Arapahoe Ave, Suite A Phone: (720) 466-3196 > Boulder, CO 80303 Fax: (303) 448-7756

1 0