Hello,
Thank you for developing and maintaining git-hound.
I'm working with it for the first time, for a specific use-case, to migrate away from another solution.
The feature...
One thing I need is the ability to exclude certain repository owners, repository names, or fully qualified repositories in a configurable way.
Hypothetical examples entries, respectively:
- github.com/someguy/*
- github.com/*/openwrt
- github.com/someguy/openwrt
When I say "exclude", I don't mean to reduce false positives necessarily - and I don't necessarily mean to add it to the code search query as a negative search - there may be dozens (or more than 100) of these exclusions.
The right approach for applying the exclusion in my view is to simply skip any results in the code search response that match the exclusions.
The real impact of this is reducing the run-time, since git-hound doesn't need to bother pulling any info with git for further inspection.
Describe the solution you'd like
The implementation: A section in config.yml for the exclusions would be ideal, I think.
With one list for owner, one for repo name, and one for full owner/repo.
exclusions:
owners:
- user1
- user2
repo-name:
- repoA
- repoB
full-repo:
- user3/repoC
- user4/repoDDescribe alternatives you've considered
Because the objective is reducing the run-time of git-hound, there's not any great alternative. Filtering after post- processing is too late, time has already neen spent using git to retrieve files.
Maybe there is already a way to do this, if so, please point me at it and I'll be out of your hair 😀
Additional context
My use-case may be a less common one, it is not a Bounty use-case. It is for continuously looking for matches for small-ish fixed/specific list of entities. These entities happen to have a LOT of matches for various reasons.
Many of those matches are repos and users that are well known at this point.
Avoiding them entirely via simple exclusion lists before git-hound even looks at the commit info would have a large reduction in the amount of work that needs to be done, which means it finished more rapidly (and less compute, and whatever else you may value as a user)
Final Note
I'm not sure how actively git-hound is maintained, and unfortunately I don't have a lot of time to offer in the way of contributing a PR for this. So my expectations are not high. But am ack (positive or negative) is greatly appreciated
Hello,
Thank you for developing and maintaining
git-hound.I'm working with it for the first time, for a specific use-case, to migrate away from another solution.
The feature...
One thing I need is the ability to exclude certain repository owners, repository names, or fully qualified repositories in a configurable way.
Hypothetical examples entries, respectively:
When I say "exclude", I don't mean to reduce false positives necessarily - and I don't necessarily mean to add it to the code search query as a negative search - there may be dozens (or more than 100) of these exclusions.
The right approach for applying the exclusion in my view is to simply skip any results in the code search response that match the exclusions.
The real impact of this is reducing the run-time, since git-hound doesn't need to bother pulling any info with git for further inspection.
Describe the solution you'd like
The implementation: A section in
config.ymlfor the exclusions would be ideal, I think.With one list for owner, one for repo name, and one for full owner/repo.
Describe alternatives you've considered
Because the objective is reducing the run-time of git-hound, there's not any great alternative. Filtering after post- processing is too late, time has already neen spent using
gitto retrieve files.Maybe there is already a way to do this, if so, please point me at it and I'll be out of your hair 😀
Additional context
My use-case may be a less common one, it is not a Bounty use-case. It is for continuously looking for matches for small-ish fixed/specific list of entities. These entities happen to have a LOT of matches for various reasons.
Many of those matches are repos and users that are well known at this point.
Avoiding them entirely via simple exclusion lists before
git-houndeven looks at the commit info would have a large reduction in the amount of work that needs to be done, which means it finished more rapidly (and less compute, and whatever else you may value as a user)Final Note
I'm not sure how actively git-hound is maintained, and unfortunately I don't have a lot of time to offer in the way of contributing a PR for this. So my expectations are not high. But am ack (positive or negative) is greatly appreciated