@simonsan and I started this discussion in discord. It's fitting to summarize and continue in here.
My use case: ignore the build output of a cargo project (i.e. ignore target directory when it shares a directory with Cargo.toml, edge-cases aside)
Current approach
Currently, one can ignore/include files based on approaches such as globs, respecting .gitignore files, etc. An initial suggestion was to respect .gitignore files. This works when file-management of a git project happens to mirror what you want to backup. It does not work when the things you want to backup don't align with what you want in your git repo, as it's not the job of .gitignore to filter what you want backed up. Personal configurations, such as IDE settings, comes to mind.
Some other scenarios, though arbitrary and contrived, illustrate the potential value of allowing some sort of programatic definition, or scriptability, to be added to the backup process:
Add inclusion/exclusion parameters based on some sort of script. E.g. "find all the files that differ from the most up to date remote branch, and include them. if this is above $FILE_SIZE, backup just the diff. if the diff is bigger that $FILE_SIZE, log an error"
Add inclusion/exclusion paramaters based on file content. I don't know why, but someone out there might want to exclude files that contain the string "foobar" within the first 0x42KiB of a file.
Add the ability to add include/exclude paramaters that apply to parts of files (e.g. "in path/to/dir/** and git status shows that there is a merge conflict, snip-out the code that is the down-stream source of the conflict" is one contrived example)
Only apply certain shell hooks according under defined include/exclude parameters.
I am curious to see where this discussion will take us.
@simonsan and I started this discussion in discord. It's fitting to summarize and continue in here.
My use case: ignore the build output of a cargo project (i.e. ignore
targetdirectory when it shares a directory withCargo.toml, edge-cases aside)Current approach
Currently, one can ignore/include files based on approaches such as globs, respecting .gitignore files, etc. An initial suggestion was to respect
.gitignorefiles. This works when file-management of agitproject happens to mirror what you want to backup. It does not work when the things you want to backup don't align with what you want in your git repo, as it's not the job of .gitignore to filter what you want backed up. Personal configurations, such as IDE settings, comes to mind.Some other scenarios, though arbitrary and contrived, illustrate the potential value of allowing some sort of programatic definition, or scriptability, to be added to the backup process:
git statusshows that there is a merge conflict, snip-out the code that is the down-stream source of the conflict" is one contrived example)I am curious to see where this discussion will take us.