Add support for linked working trees (fixes #43)

[hartwork]

Fixes #43

[SuperSandro2000]

I tried this branch and it doesn't crash anymore and correctly skips those branches.

[~/src/nixpkgs][  google-cloud-access-cont..][last: 0m 0s] git-delete-merged-branches -y
Skipped refreshing branches because of detached HEAD.
Skipped branch 'google-cloud-access-context-manager' because it is currently checked out.
Skipped branch 'uutils-coreutils-stdenv' because it is currently checked out.
Skipped branch 'google' because it is currently checked out.
Skipped branch 'herepy' because it is currently checked out.
Skipped branch 'rehex' because it is currently checked out.
....
66 local branch(es) deleted.
...
30 remote branch(es) deleted.

[~/src/nixpkgs][  google-cloud-access-cont..][last: 53m 44s]

So I think this branch is ready to go but I encountered the next problem. It took 53 minutes and 44 seconds to run it on my fork of nixpkgs. I deleted 99 branches with this run but still have over 800 locally (counted with git branch | wc -l). Do you think you could improve this a bit? Maybe some parts can be heavier parallised or some requests can be reduced by doing heavier caching or asking the API for more information in bulk?

[hartwork]

I tried this branch and it doesn't crash anymore and correctly skips those branches.

@SuperSandro2000 cool, thanks for testing.
To be fair, exiting with a known handled error and a message is not crashing. A segfault or a backtrace is crashing. That's a difference in my book.

So I think this branch is ready to go

Excellent! 🎉

but I encountered the next problem. It took 53 minutes and 44 seconds to run it on my fork of nixpkgs. I deleted 99 branches with this run but still have over 800 locally (counted with git branch | wc -l). Do you think you could improve this a bit? Maybe some parts can be heavier parallised or some requests can be reduced by doing heavier caching or asking the API for more information in bulk?

That's an interesting and tricky topic. git-delete-merged-branches let's the Git CLI do 99% of the work, as can be seen when adding the --verbose argument. NixOS Git repo is likely one of the biggest on the planet and from my work on Gentoo Linux I know that the usual millisecond character of Git goes away with repositories of that size, for some operations. There are no API calls other than Git CLI made, and the calls to git branch (-d|-D) and git push --delete are already being called in batches with multiple branches rather than single ones. So it could be Git itself, the SSH push part, process forks (while I doubt that), or the Python code in git-delete-merged-branches. If performance with big repositories matters to you, please make a new ticket with details to reproduce your long-running scenario and then we can see where the runtime is spend, e.g. using a Python profiler. Don't get your hopes up though, your repository is big and there is no problem like that with small repositories, so the problem may be inherent and unfixable, but that remains to be seen.

[SuperSandro2000]

Thanks. I am looking into which git commands take so long in the next days and open an issue if I have any ideas how to improve this. I already have one idea that git push to GitHub might be the slow part. Sometimes it takes minutes for no good reason. Other than that I am already using all caching features of git and normal git operations like git status are already instant with caching compared to without where they took a few seconds.

[hartwork]

Other than that I am already using all caching features of git and normal git operations like git status are already instant with caching compared to without where they took a few seconds.

Could you elaborate what caching features you refer to — where can I read more about those?

[SuperSandro2000]

Right now I set core.untrackedCache = true but you might as well set feature.manyFiles (https://git-scm.com/docs/git-config#Documentation/git-config.txt-featuremanyFiles) which also enables a newer index format which should help. Did not try the feature flag but untrackedCache really improves things if you are on a somewhat up to date machine.

I also used core.fsmonitor (https://git-scm.com/docs/git-config#Documentation/git-config.txt-corefsmonitor) for a while but it is still a bit buggy sometimes.

Last but not least I replaced the git status in my bash prompt with a gitstatusd implementation which is faster by factor 10x.

[hartwork]

Right now I set core.untrackedCache = true but you might as well set feature.manyFiles (https://git-scm.com/docs/git-config#Documentation/git-config.txt-featuremanyFiles) which also enables a newer index format which should help. Did not try the feature flag but untrackedCache really improves things if you are on a somewhat up to date machine.

I also used core.fsmonitor (https://git-scm.com/docs/git-config#Documentation/git-config.txt-corefsmonitor) for a while but it is still a bit buggy sometimes.

Last but not least I replaced the git status in my bash prompt with a gitstatusd implementation which is faster by factor 10x.

Thanks for these pointers. manyFiles seems to make things go faster over here.

Thanks. I am looking into which git commands take so long in the next days and open an issue if I have any ideas how to improve this.

It seems that git cherry is not cheap on the NixOS repository. By passing --effort=1 I get down to 16 seconds runtime over here. Maybe --effort=1 is good enough in your context, default is --effort=2 which includes use of git cherry.

[SuperSandro2000]

It seems that git cherry is not cheap on the NixOS repository. By passing --effort=1 I get down to 16 seconds runtime over here. Maybe --effort=1 is good enough in your context, default is --effort=2 which includes use of git cherry.

With --effort 1 I got down to 2 seconds without deleting any remote branches. I probably add this as default and maybe run ´´--effort 2`` once in a while to delete dangling branches.

I didn't really look at the options before so I missed this.