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

Feature: Configurable exceptions for gitignore #1168

Open
intgr opened this issue Jun 19, 2024 · 2 comments
Open

Feature: Configurable exceptions for gitignore #1168

intgr opened this issue Jun 19, 2024 · 2 comments
Labels
A-config Area: Related to the config file functionality and format C-enhancement Category: New feature or request

Comments

@intgr
Copy link
Contributor

intgr commented Jun 19, 2024

I have tons of git repositories under my home directory, which I want to keep backed up.

I want to keep git-ignore = true in my settings to ignore build artifacts and most unnecessary junk in repositories.

But there are certain paths, which are gitignored (I don't want to share with other developers), but still want backed up:

  • _local - I often create such a directory in a repository root, which can contain partial experiments, personal notes, etc.
  • .idea - if I ever run into a disaster recovery scenario, it would greatly speed up recovery if per-project IDE configuration (IntelliJ IDEA) is preserved.

I might put in the effort to submit a PR for this, but first I want to ensure the feature makes sense to others.

I guess this would be an additional setting. Naming is a bit complicated, since it's a double negative, "git-ignore-ignores" probably wouldn't fly. 😄

I think this should only apply if a path would be matched by glob = [...], but is excluded by .gitignore. So glob exclude rule can still exclude _local from a backup.

Maybe git-ignore-exceptions = ["_local", ".idea", "maybe*glob*syntax*too"]

git-ignore-override?

@github-actions github-actions bot added the S-triage Status: Waiting for a maintainer to triage this issue/PR label Jun 19, 2024
@aawsome aawsome added this to the Overwork includes/excludes milestone Jun 26, 2024
@aawsome
Copy link
Member

aawsome commented Jun 26, 2024

Thanks @intgr for opening this issue and sorry for the late reply!

I think this is somewhat related to a general overworking of how to include/exclude. I created a milestone for that: https://github.com/rustic-rs/rustic/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Overwork+includes%2Fexcludes%22

The current state is:

  • we only have local fs or stdin as source
  • for local sources we use the ignore crate and its capabilities to include/exclude

I think we should have

  • a general source trait which can be implemented by many sources
  • a way to include/exclude which is common for all sources, e.g. give globs as argument or in a (local) file to load.
  • additional possibilities to specify exclude options only for some sources
  • abilities to priorize includes/excludes

If you want to work on this, you are very welcome! I'll try to support as much as I can but must say that I am unfortunately a bit short on time, currently...

@intgr
Copy link
Contributor Author

intgr commented Jun 26, 2024

abilities to priorize includes/excludes

Do you have any concrete thoughts on what the configuration schema for that might look like? If we want full flexibility with arbitrary cascades of includes/excludes, seems like it could get pretty complicated. But I haven't thought much about this.

Something like git-ignore-exceptions that I proposed above would be a step in the opposite direction?

@nardoor nardoor added C-enhancement Category: New feature or request A-config Area: Related to the config file functionality and format and removed S-triage Status: Waiting for a maintainer to triage this issue/PR labels Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-config Area: Related to the config file functionality and format C-enhancement Category: New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants