[WIP] RAT-473: take global gitignore into account #433
Conversation
Take into account exclusions from the global gitignore file if it is present in the default location. It's kind of icky to read environment variables in code called from an enum constructor, but I didn't see a more elegant solution yet either. Relatedly, I have not yet created a unit test (or made sure that a global gitignore will not interfere with a global gitignore being present), hence the WIP status. https://git-scm.com/docs/gitignore
|
|
||
| /** The location of the global gitignore file to process */ | ||
| private static String globalGitIgnore() { | ||
| String xdgConfigHome = System.getenv("XDG_CONFIG_HOME"); | ||
| if (xdgConfigHome != null && !xdgConfigHome.isEmpty()) { | ||
| return xdgConfigHome + File.pathSeparator + "git" + File.pathSeparator + "ignore"; | ||
| } else { | ||
| String home = System.getenv("HOME"); | ||
| if (home == null) { | ||
| home = ""; | ||
| } | ||
| return home + File.pathSeparator + ".config" + File.pathSeparator + "git" + File.pathSeparator + "ignore"; | ||
| } | ||
| } |
There was a problem hiding this comment.
Have you tested this on a windows system? I just got back from FOSDEM and am trying to clean up a bad merge so I can't check this right now but, I think that the slashes are required to be "/" in this pattern list. There are methods that will convert them for you -- but again that is in the code I am trying to fix.
| private static String globalGitIgnore() { | ||
| String xdgConfigHome = System.getenv("XDG_CONFIG_HOME"); | ||
| if (xdgConfigHome != null && !xdgConfigHome.isEmpty()) { | ||
| return xdgConfigHome + File.pathSeparator + "git" + File.pathSeparator + "ignore"; |
There was a problem hiding this comment.
Are you certain that the default GIT process is to ignore XDG_CONFIG_HOME if it is empy? An empty XDG_CONFIG_HOME could be a way to ignore the HOME based isgnore.
Never mind the above comment. You are correct. However, for complete implementation you need to read a file specified by core.excludesFile in the user’s ~/.gitconfig.
I am also concerned about doing this automatically. It feels like it should be part of the GitIgnoreProcessor. So that users can turn it on/off. We also need to think long and hard about reading files outside of the current directory tree.
The GitIgnoreProcessor is currently undergoing changes which I hope we will have completed by the end of the week. The problem is a massive PR that I am breaking out into smaller reviewable chunks.
Once that is completed, and if you are willing to write the code to read the ~/.giconfig we can then merge this into the GitIgnoreProcessor.
There was a problem hiding this comment.
I'll wait until your GitIgnoreProcessor work is finished
There was a problem hiding this comment.
Would it make sense to provide this as a separate configuration option? - I wonder if it takes too much time to find the global ignore file on all platforms/operating systems upon each run. WDYT?
There was a problem hiding this comment.
Would it make sense to provide this as a separate configuration option?
I'll have a look if/how that fits in the new structure Claude is preparing. I think it'd make sense to follow what git does by default, but having a way to suppress it could be good.
I wonder if it takes too much time to find the global ignore file on all platforms/operating systems upon each run. WDYT?
That sounds unlikely to me: finding it is only 1-2 environment variable lookups and opening 1 file. Given RAT then proceeds to open every unignored file in the repo, the extra time seems negligible?
ottlinger
changed the title
raboof
changed the title
Done (RAT-473). Yes, I put some things in there for development tools that I use and that use files in the project directory. That way I don't need to have a perpetually-dirty .gitignore in the project or contribute those unusual special cases to the upstream .gitignore. |
ottlinger
changed the title
|
@raboof Are some of the things you put in your private ignore file found in other StandardCollection entries? Would it make sense to create more StandardCollection entries for anything that is missing? The changes that you want to work against are in Pull request #439
See Bascically the system works by creating |
|
@raboof all code changes are now in master. Please feel free to build against that. There are more changes coming but they are mostly testing and should not impact your changes. |
Take into account exclusions from the global gitignore file if it is present in the default location. It's kind of icky to read environment variables in code called from an enum constructor, but I didn't see a more elegant solution yet either. Relatedly, I have not yet created a unit test (or made sure that a global gitignore will not interfere with a global gitignore being present), hence the WIP status.
https://git-scm.com/docs/gitignore