romkatv
Merge from upstream libgit2
Why not?
It's work.
And what about pushing your changes upstream? Is it feasible?
Might be feasible. I won't be doing it though.
What will you do with repos that will use sha256 for instance? Or any other features that may affect the existing workflow.
I'm willing to help with merging (in either direction). The question is if you're open for such a PR.
Oh great :)
I'm on it then.
I got to it because I'm trying to debug why worktree doesn't work on Windows, and when I compiled gitstatus I had many compiler warnings coming from libgit2 :)
FWIW, my personal advice would be to not use gitstatus. If I manage to muster enough will power for the final contribution to gitstatus/powerlevel10k, that would be getting rid of gitstatusd. Since the time I wrote it, git has been getting faster, so it's not as awfully slow to use git nowadays. The big advantage is that it won't require ongoing maintenance to stay on top of git development.
Interesting. Is it possible to rerun the benchmarks you did back then, and see if upstream git (or libgit2) had closed the gap (especially on Windows, I'm concerned about fs performance and process spawning time on msys...)?
Must be possible but it's work.
The good thing is that you can try various solutions for yourself and see whether plain git is fast enough for you.
Is there a way to switch between gitstatus and "git status" in powerlevel10k?
There is POWERLEVEL9K_DISABLE_GITSTATUS=true but it incidentally also disables async git status computation. My remark above referencing the final contribution was about removing this coincidence.
@romkatv I tried to proceed with this, but at least on Windows, it looks like gitstatusd is actually slower than git command-line (probably because MSYS indexing is different than Git for Windows, which is built on mingw64, and uses native paths).
The advantage of gitstatusd is that it works asynchronously, so the prompt appears immediately without delays, unlike command-line git.
How hard should it be to make git command-line async as well? If you believe it is feasible for someone without any experience with zsh (I do have experience with bash though), please give me some pointers and I can try to implement it.
It's feasible for someone who's good at programming in general. It's not a small project though. I'm afraid I cannot give any pointers other than in the direction of the overall source code.
For what it's worth, I've also been maintaing a forward port of this against evolving upstream, which should be visible here: https://github.com/ajrh1/libgit2/tree/romkatv-1.8.1
I did a very quick eyeball comparison just now against orgads tree. Leaving aside the deleted files, as my branch I'd tried to keep as a rebase of roman's individual commits so is similarly stripped down, the diff-filter=M changes look unsurprisingly very similar- I will likely go through the remaining diffs carefully to see which seems most correct.
I recognize the point about the whole being on life-support now and of questionable necessity if git has become faster, but I like the speed and greatly appreciate the work that Roman has put in.
Actually I'm not sure about my last comment regarding the speed difference. I switched back to gitstatusd, and it does feel faster than git. I'll need to do real benchmarks to compare them, but I don't know when I'll be able to do that.
Is there a preferred place to continue this discussion? Don't want to keep raising notifications here if @romkatv you want to move on from the project. FWIW, I seem to have a working prototype of maintaining a single persistent gitstatusd rather than running one per shell, which seems to help a bit with Windows startup speed, and is aesthetically lighter. It's just a wrapper script that connects gitstatusd to a unix domain socket, and so I was thinking next to build the socket handling into gitstatusd. I wasn't sure originally how close to keep to the original style and backward compatibility, but if this repo is somewhat finalized then I'll maybe branch out a bit.
You can leave a link here so that others might find your fork, and then continue the discussion there.
FWIW, I've never went this path because the performance benefits are next to nothing, and the extra security concerns are non-trivial (think of users with different privileges having access to the same gistatusd).