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

support global gitignore config #9

Closed
BurntSushi opened this issue Sep 21, 2016 · 10 comments
Closed

support global gitignore config #9

BurntSushi opened this issue Sep 21, 2016 · 10 comments
Labels
bug A bug.

Comments

@BurntSushi
Copy link
Owner

e.g., $HOME/.config/git/ignore or $XDG_CONFIG_HOME/git/ignore or whatever file is specified by the configuration variable core.excludesFile. Another source might be $GIT_DIR/info/exclude.

@BurntSushi BurntSushi added the bug A bug. label Sep 21, 2016
@BurntSushi
Copy link
Owner Author

While supporting core.excludesFile or a global .gitignore seems easy enough, support $GIT_DIR/info/exclude is actually a little tricky. There are two issues:

  1. Firstly, it's an additional file to stat for in every directory we descend. That list of files is currently at two (.rgignore and .gitignore), and I know we'd like to bump it to three so we can include .hgignore too. Adding $GIT_DIR/info/exclude would bring this list to 4 entries. Owch.
  2. A $GIT_DIR/info/exclude file seems to have precedence strictly lower than all .gitignore files in the current directory all the way up to the parent directory. (See man gitignore). This means we need to: 1) Check all .gitignore files, 2) then check all $GIT_DIR/info/exclude files and finally 3) check the global gitignore config.

We should at least support core.excludesFile. Supporting $GIT_DIR/info/exclude seems like it might cost us too much for little gain. (My impression is that it isn't widely used.)

@Deewiant
Copy link

My 2¢: I've used $GIT_DIR/info/exclude in practically every repo I've worked on for a significant period of time, whereas I've never used core.excludesFile, so for me the priorities there would be exactly reversed.

One alternative solution might be to have a parameter or separate tool to auto-generate one or more .ignore files based on these sources that are otherwise trickier to handle. The usefulness of this is predicated on people not committing their .ignore files. I'm not sure how likely that is...

@vi
Copy link

vi commented Sep 26, 2016

Maybe there should be an option for specifying additional (or replacement) ignore files manually?

@BurntSushi
Copy link
Owner Author

@vi That's always an option, but it's not particularly satisfying.

@rjayatilleka
Copy link

I also think $GIT_DIR/info/exclude would be more useful than core.excludesFile. But if there is a worry about performance, I think the flag for specifying extra ignore files is best. It can always be aliased or put in a short function.

@Julian
Copy link

Julian commented Oct 10, 2016

(Just for some counterbalance -- I'm certainly in the bucket of people you originally mentioned. $XDG_CONFIG_HOME/git/ignore is way way way more important for me.)

@john-kurkowski
Copy link

core.excludesFile for me

@rjayatilleka
Copy link

Actually, changed my mind. core.excludesFile for me too. How high on the priority list is this feature btw?

@BurntSushi
Copy link
Owner Author

It's being worked on.

On Oct 20, 2016 5:51 PM, "Ramith Jayatilleka" notifications@github.com
wrote:

Actually, changed my mind. core.excludesFile for me too. How high on the
priority list is this feature btw?


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAb34puYJ9ir4rQPWTT_kcOTPAHu0mlWks5q1-JegaJpZM4KCvdR
.

BurntSushi added a commit that referenced this issue Oct 30, 2016
This PR introduces a new sub-crate, `ignore`, which primarily provides a
fast recursive directory iterator that respects ignore files like
gitignore and other configurable filtering rules based on globs or even
file types.

This results in a substantial source of complexity moved out of ripgrep's
core and into a reusable component that others can now (hopefully)
benefit from.

While much of the ignore code carried over from ripgrep's core, a
substantial portion of it was rewritten with the following goals in
mind:

1. Reuse matchers built from gitignore files across directory iteration.
2. Design the matcher data structure to be amenable for parallelizing
   directory iteration. (Indeed, writing the parallel iterator is the
   next step.)

Fixes #9, #44, #45
@BurntSushi
Copy link
Owner Author

Fixed in #202.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A bug.
Projects
None yet
Development

No branches or pull requests

6 participants