Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sl is very slow in git repo #929

Open
nicktogo opened this issue Aug 4, 2024 · 2 comments
Open

sl is very slow in git repo #929

nicktogo opened this issue Aug 4, 2024 · 2 comments
Assignees
Labels
transparent-git Issues related to transparent git support, where you use `sl` commands in preexisting git repos

Comments

@nicktogo
Copy link

nicktogo commented Aug 4, 2024

Hello, I know dotgit mode is still being developed. But sl command is very slow in my large mono git repo. Here is a truncated trace. It spends quite some time on a git status command.

If I run git status manually, it does spend quite some time on refreshing index, then sl command becomes fast again.
But if I did some sl change, e.g. amend/commit, sl will be slow again on git status. I'm guessing it spends some time on refreshing index again.

I'm using latest release. Let me know what else info you need.

Glad that dotgit is being worked on, thank you so much!

➜   EDENSCM_LOG=debug sl status
...
2024-08-04T04:39:02.603878Z  INFO run:status: workingcopy::workingcopy: enter
2024-08-04T04:39:02.603903Z DEBUG run:status: workingcopy::filesystem::dotgit: pending_changes (DotGitFileSystem) include_ignored=false
2024-08-04T04:39:02.603920Z DEBUG run:status: gitcompat::rungit: git command: ["--git-dir=MY_REPO_PATH/.git", "--no-optional-locks", "status", "--porcelain=1", "--ignore-submodules=dirty", "--untracked-files=all", "--no-renames", "-z", "--ignored=no"]
2024-08-04T04:39:34.597473Z  INFO run:status:compute_status: workingcopy::status: enter
@evangrayk evangrayk added the transparent-git Issues related to transparent git support, where you use `sl` commands in preexisting git repos label Sep 4, 2024
@quark-zju
Copy link
Contributor

It's --no-optional-locks (added by 6b1912b). The difficult choice is:

  • Without --no-optional-locks, status triggered by automation might create the "lock" and other non-automation commands will error out.
  • With --no-optional-locks, status will eventually be slower, maybe until a checkout (I'm not an expert in this area, and not sure).

Do you use the CLI or ISL? If you use the CLI we can change --no-optional-locks to automation (ISL) only. Then CLI status would probably be okay. If you use ISL exclusively then it's tricker to fix.

@nicktogo
Copy link
Author

I mostly use ISL for commit, stacking, but I do use CLI sometimes, but basically just sl status/diff for some linters that we have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
transparent-git Issues related to transparent git support, where you use `sl` commands in preexisting git repos
Projects
None yet
Development

No branches or pull requests

3 participants