I propose that there should be a checkbox option in the projectorganizer settings that says:
[] Get project files from git repo
If checked, the file pattern textbox turns grey and instead geany uses the output from the command `git ls-files` to get a list of files currently under source control in the git repo. Most of the times these are exactly the files that you want to have in the project as project files.
Alternatively, it could detect and use VCS ignore files like `.gitignore` and `.hgignore` in addition to or instead of what's listed in the preferences dialog. This has the advantage of not requiring to shell-out to a subprocess, and will also keep listing files/directories which are not excluded by main ignore file but which are excluded by others like the `.git/info/exclude` ignore file.
@codebrainz not sure shelling to git is more expensive than trawling a whole directory tree, guess it depends on the tree size, but definitely using [libgit2](https://libgit2.github.com/) library would be cheaper than both.
It already finds the files, it would just exclude from what it found by ignoring the files in `.gitignore`s instead of/in addition to what's configured in preferences. This way it would allow listing/working on untracked files which haven't been added to Git yet.
Well I read it as using git was to replace trawling the tree, not in addition to it. But yeah it won't include untracked files.
I don't think anyone is talking about performance, I believe this issue is to avoid specifying the same information in two places (project prefs and git). My suggestion was just to avoid having to add a whole new mode to the plugin and a bunch of extra coding effort.
@codebrainz and @elextr
Yes, the intention is to avoid duplicating the same information, the [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) principle. And also the .gitignore allows for quite advanced file inclusion/exclusion rules that is hard to replicate in the project files list anyway as well. So I think it would be very beneficial to leverage this functionality from git / libgit2 instead of parsing the .gitignore ourself.
And, I really like the idea to also get untracked files via the "git status" command. This way it would also be possible to color code or otherwise mark files in the tree depending on their git status like Modified/Untracked.
This is a feature available in atom and vscode but it is very helpful because you get an immediate visual overview of the project when you are working. The terminal and git status commands are just some clicks away but a colormarker in the tree is just a glance and some milliseconds away.
@gntech Sorry, didn't notice this bug report earlier (better to @techee me because I'm not subscribed to receive all the comments for the project).
I would definitely support such a feature if anyone wants to implement it (on the other hand I probably won't have time for this myself). Some comments to such an implementation:
1. The glob patterns are necessary for "find in files" because grep can only use these for the `--include=` command line option. So one would have to synthesize a glob version that would be some approximation of .gitignore rules.
2. In order to have the modified files information, it will probably be necessary to rewrite the project file tree code completely. It is completely static now and only changes when you refresh the project. I wrote it this way because I needed it for a huge project and wanted it to be as fast as possible (and having the implementation as simple as possible). I think it's possible to preserve a good performance even when there's some file monitoring (this is something I'd really like to have preserved for the plugin) but it definitely won't be trivial to implement right.
github-comments@lists.geany.org