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

Supporting both in-repo and local rules #737

Closed
1 task done
amyq opened this issue Dec 11, 2023 · 3 comments
Closed
1 task done

Supporting both in-repo and local rules #737

amyq opened this issue Dec 11, 2023 · 3 comments

Comments

@amyq
Copy link

amyq commented Dec 11, 2023

Check for existing issues

  • Completed

Describe the feature

(I've been idly thinking about how to solve this problem for some time.)

On the technical-writing team at GitLab, we copy the GitLab style into every Git repository our writers work in, but not all the rules that we propose for the GitLab style get accepted. Several of us have wanted the ability to stack local / personal rules atop in-repo rules. I haven't thought of a smart way to do this. I've opened up https://gitlab.com/gitlab-org/gitlab/-/merge_requests/139279 to look for a shorter-term solution, but Evan and Marcel both suggested I bring it up here, too.

Here's the real-life example: a rule called MayMightCan.yml wasn't accepted into the gitlab style. However, I'd still like to use it locally, because I'm (redacted) terrible at remembering to use the right word. Ideally, I'd have a second location (let's assume in my user folder) where I could drop in this extra rule, and have it available to me in all the repos (10+) that I work in.

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/139279 tries to find a kludgy path forward and proposes:

  1. adding a second style folder to the gitlab repo
  2. calling it either personal or local.
  3. adding a line to the root .gitignore file to ignore everything in doc/.vale/local

This proposed kludgy approach would be fine. It beats the nothing I currently have. However, I'd love to use MayMightCan.yml regardless of what repo I'm working in at the time.

Feel free to tell me this is an edge case for someone who touches a LOT of projects. It might well be.

@jdkato
Copy link
Member

jdkato commented Dec 12, 2023

This will be possible with the proposed changes in #688 (specifically, the notion of a default StylesPath).

@jdkato
Copy link
Member

jdkato commented Jan 10, 2024

This is out now.

@amyq
Copy link
Author

amyq commented Jan 10, 2024

Wild. I ask and then … boom, added. Not gonna lie; this is some serious wish fulfillment here.

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

No branches or pull requests

2 participants