![]() ![]() Applications/Xcode.app/Contents/Developer/usr/bin/git Is your head spinning yet? The actual tools are inside the Xcode app bundle: $ xcrun -find git By the way, if you're looking for /usr/lib/libxcselect.dylib on disk you may not find it, because Big Sur. The /usr/bin/git executable on macOS is just a stub that calls the _xcselect_invoke_xcrun function in the /usr/lib/libxcselect.dylib library, which you can see by using the /usr/bin/otool command-line tool - which coincidentally is also just a stub that calls the _xcselect_invoke_xcrun function. So I tried rebooting again, and then the issue occurred again!įor the impatient who don't care to hear the story of how I discovered the cause, I'll cut to the chase. Puzzled, I could only think of one thing out of the ordinary: I had just rebooted my Mac. ![]() ![]() Indeed it was instantaneous the next time I ran it on the same repository. This was highly unusual, as git status is mostly instantaneous for me. I ran git status on a newly created, very small repository, but the command took more than 10 seconds to finish. I should also mention that this is win Windows Defender and OneDrive running and OneDrive is set to backup the "Documents" directory.Why Xcode tools are slow after reboot Articles index Why Xcode tools are slow after reboot Augby Jeff Johnson This does show that WSL it is still slow relative to native linux this command used to take around 0.100s - 0.200s in the Documents directory for me so I'll call that a huge win. I then ran time git status on each of them 10 times. I cloned the repo onto all the machines in the windows case I cloned it into my "Documents" folder as well as in the WSL home folder. I don't have the specs for allot of these machines but I know the hardware is very different so take all of this with some salt. My laptop (windows +WSL ubuntu 18.04), a university server(ubuntu 16.04), a university lab computer (ubuntu 16.04), and my own personal server from cybera (ubuntu 18.04). I cloned the same repo on 4 different machines. So I did some VERY BASIC benchmarking with a git repo. It seems to be a likelier outcome than Linux desktop supporting various Windows/Mac -only software I need, not to mention more affordable than switching to mac hardware. I'm excited for the filesystem IO issues in WSL to be worked out, as it will make windows a significantly more pleasant development environment. If I find I work on a large enough portion of the repo that sparse checkout doesn't bring performance within a reasonable range, I'll clone multiple copies of the repo with more aggressive sparse checkout settings, a separate copy for each "context" I'm working in.Īdditionally, it helps to run git gc -aggressive periodically be sure to run it after making significant changes to sparse checkout settings. Though not ideal, working with massive repos is often inevitable, and it may not always be possible to break them down into smaller repos for political and/or convenience reasons. git/info/sparse-checkout, then running git read-tree -mu HEAD. The workaround I've opted for is to limit my working directory by setting git config core.sparseCheckout true and excluding directories I don't need by editing. This problem has plagued me for quite some time.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |