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