support limiting magit-status to directory

[CeleritasCelery]

The one common use case that necessitates me returning to command line git is limiting my operations to sub directory (git status .). I often work with large git repos that will take nearly 10 minutes to run git status (even outside of magit). However I only care about a very small part of the repo and therefore can run git status in that directory only. In magit, D =f will provide functional equivalence (aside from still enumerating all untracked files) but still takes as long as running on the whole repo.

I asked about this on the gitter and did some googling and it appears that magit does not support this. This would be a highly useful feature addition, though I do not know the scope of the changes to the magit code base.

[vermiculus]

Bonus if you could run git-status on a list of directories; I have the same issue at work (albeit using SVN) where I only work in three to four different directories (e.g., /some/path/for/me and /some/other/path/for/me) for any given project; svn status can take ages. If git-svn could handle this (abhorrent) setup...

[vermiculus]

Bonus if you could run git-status on a list of directories; I have the same issue at work (albeit using SVN) where I only work in three to four different directories (e.g., /some/path/for/me and /some/other/path/for/me) for any given project; svn status can take ages. If git-svn could handle this (abhorrent) setup...

[tarsius]

I often work with large git repos that will take nearly 10 minutes to run git status (even outside of magit).

Magit is not expected to work well in such a scenario. I have one repository like this too. It has a few thousand submodules, which brings git status to its knees. I don't use Magit in that repository.

In magit, D =f will provide functional equivalence (aside from still enumerating all untracked files) but still takes as long as running on the whole repo.

Before I implement anything and that then turns out to not be sufficient to make Magit usable in this scenario, please determine which features are problematic.

I suspect that it is the mentioned section listing the untracked files. Remove the respective function from magit-status-sections-hook and test if performance is acceptable now. If not, then also remove other section inserters until you have a list of the problematic ones.

Other section inserters could be taught to respect the value set by D =f, that value could be displayed at the top of the buffer, and a command to set it more conveniently could be added.

[tarsius]

I often work with large git repos that will take nearly 10 minutes to run git status (even outside of magit).

Magit is not expected to work well in such a scenario. I have one repository like this too. It has a few thousand submodules, which brings git status to its knees. I don't use Magit in that repository.

In magit, D =f will provide functional equivalence (aside from still enumerating all untracked files) but still takes as long as running on the whole repo.

Before I implement anything and that then turns out to not be sufficient to make Magit usable in this scenario, please determine which features are problematic.

I suspect that it is the mentioned section listing the untracked files. Remove the respective function from magit-status-sections-hook and test if performance is acceptable now. If not, then also remove other section inserters until you have a list of the problematic ones.

Other section inserters could be taught to respect the value set by D =f, that value could be displayed at the top of the buffer, and a command to set it more conveniently could be added.

[CeleritasCelery]

For me, removing magit-insert-untracked-files from magit-status-sections-hook made a world of difference in this particular repo. If it respected Limit to files that could be a huge help. I imagine the more section headers that can be limited to a directory, the better.

that value could be displayed at the top of the buffer

It looks like it is already displayed as Filter!

command to set it more conveniently could be added

It would be especially useful if it could be set before the call to magit-status.

[CeleritasCelery]

For me, removing magit-insert-untracked-files from magit-status-sections-hook made a world of difference in this particular repo. If it respected Limit to files that could be a huge help. I imagine the more section headers that can be limited to a directory, the better.

that value could be displayed at the top of the buffer

It looks like it is already displayed as Filter!

command to set it more conveniently could be added

It would be especially useful if it could be set before the call to magit-status.

[tarsius]

magit-insert-untracked-files and magit-insert-tracked-files now honor magit-diff-section-file-args. Many other sections - basically everything diff-related - already did that. For other sections it would make less sense - in particular I think this shouldn't be done for log sections.

It would be especially useful if it could be set before the call to magit-status.

I have marked magit-diff-section-file-args to be safe as a local variable local variable, so now you can set it in ~/path/to/repo/.dir-locals.el (or .dir-locals-2.el if the former already exists).

((magit-status-mode
  (magit-diff-section-file-args . ("lisp/"))))

Use the directory you most commonly want to limit the repository too. When the status buffer is first created, then it will use that value, but you can then change it using D =f ... g.

I probably won't add a separate command to set this variable.

[tarsius]

magit-insert-untracked-files and magit-insert-tracked-files now honor magit-diff-section-file-args. Many other sections - basically everything diff-related - already did that. For other sections it would make less sense - in particular I think this shouldn't be done for log sections.

It would be especially useful if it could be set before the call to magit-status.

I have marked magit-diff-section-file-args to be safe as a local variable local variable, so now you can set it in ~/path/to/repo/.dir-locals.el (or .dir-locals-2.el if the former already exists).

((magit-status-mode
  (magit-diff-section-file-args . ("lisp/"))))

Use the directory you most commonly want to limit the repository too. When the status buffer is first created, then it will use that value, but you can then change it using D =f ... g.

I probably won't add a separate command to set this variable.

[CeleritasCelery]

Thanks!

[CeleritasCelery]

Thanks!