![]() ![]() Guarantee that the server is the computer you think it is. The server's host key is not cached in the registry. When I tried to create ssh-key from Putty(windows), it goes further, but waits with this following message! Please make sure you have the correct access rights and the repository Git -c diff.mnemonicprefix=false -c core.quotepath=false fetch origin However, when I try to git pull in SourceTree, I get this. I could git pull and do other operations from Git-bash. They've forced me to abandon them.I Generated ssh keys and configured my git and SourceTree. I'm a core fan of SourceTree, but the developer's seemingly blasé attitude and lack of priority for a HUGE DEAL BREAKING issue for us-over the course of not days or weeks but years-has left me disheartened. almost like when I left Firefox for Chrome after a Firefox bug they wouldn't (or couldn't) resolve. There's something bittersweet about this change. The switch took just a tiny bit to get familiar with, but I can leave it open all day with no CPU spiking at 100%! And it does the job quite well. So for the past two weeks, I switched over and have been using GitHub Desktop (also free). But that didn't save Friendster when Friendster was abandoned by its users for performance issues (failure to scale). I'm sure all the developers are nice people who put their hearts and soul into this product. SourceTree probably could offer a "disable expensive CPU history feature" option checkbox, as a patch while they rebuild the app, but I don't think they care to offer a patch or work-around? The solution by SourceTree is not to fix it, but to block user commenting because comments in the original thread have "devolved," as worded above bgannin. ![]() They've been saying it's on the roadmap for ages, and I don't think it is. You'll need to cmd+r more often to manually refresh, but i'll take that over the cpu problem until they can get it fixed. I say spike, which implies a brief time, but it sometimes it stays pegged over 100 until I close the app.Īfter the changes I'm seeing spikes between 14-25% cpu while I'm using the app. I haven't seen the usually spikes to 100+% cpu usage. I did this yesterday, and I've been monitoring it today. "Check default remotes for updates every minutes" "Refresh automatically when files change" Next I removed any setting that does any syncing or or auto refreshing. I have 12 in there now down from about 30. I removed the bookmarks for all the repo's I am unlikely to touch any time soon. I recently changed a few things that seem to have helped a bit that I'll share with the hope it helps someone else.įirst, I had tons of repositories linked in SourceTree. This is / was still a problem for me on MacOs even on version 4.0.1. In short, if you're experiencing high CPU usage, try viewing different history entries and/or changing the diff pane's "lines of context" setting and see if that helps. But obviously there are many differences between the computers, including their screen sizes. I've tried viewing the same history entry on a Mac with Apple's M1 chip and also on a Windows computer, but didn't get the same high CPU usage. This is all on a Mac with an Intel processor. If I'm not mistaken, simply changing the pane's size fixed the issue a couple of times too, but not consistently. The only thing that stands out about the specific textual changes is that one of the lines before the change is rather long (290 characters). So this is not about anything else in my original repo, but something about the type/pattern of changes that are displayed in the diff pane. I've tried creating a clean repo with a single file and just 2 commits that replicate the same textual changes, and got the exact same high CPU use issue. The CPU usage is consistently high only when the specific history entry is selected. However, selecting other History entries or changing the diff pane's "lines of context" setting to a different value fixes the issue immediately. Switching to other apps doesn't make a difference CPU usage remains very high. A specific set of changes to a text file has been causing SourceTree's CPU usage to skyrocket and stay that way even though everything seems to be working fine otherwise (the diff pane displays the changes correctly and SourceTree is still fully responsive). In my case, the culprit ended up being the file diff pane in History mode. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |