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 specifying restic options #1

Open
tionis opened this issue Oct 20, 2024 · 2 comments
Open

Support specifying restic options #1

tionis opened this issue Oct 20, 2024 · 2 comments

Comments

@tionis
Copy link

tionis commented Oct 20, 2024

I'm using restic via an append only ssh backend (using ssh forced commands) and would like to use the same or a similar backend for git-remote-restic.
To use the backend with normal restic backups I do something like restic -o rclone.program='ssh backup-host forced-command' -r rclone: backup.
This approach is also explained here.
Perhaps such an options could be encoded in the remote string?

@CGamesPlay
Copy link
Owner

Encoding in the remote string sounds like it could get very unwieldy. One option is to utilize the gitconfig file to store these options. This would look like:

  1. Use a named git remote. Now running git push <name> will run git-remote-retic <name> <url>.
  2. The tool can then read any additional keys from the git config, for example we could create remote.<name>.restic_option which would contain an option string (e.g. remote.<name>.restic_option = rclone.program='ssh backup-host forced-command'). I recommend specifying a single option because git config keys can be specified multiple times, and then you don't have to invent a quoting system.
  3. Call options.Parse to parse them; apply them to the config.

I would be willing to review a PR that added this kind of behavior.

@tionis
Copy link
Author

tionis commented Oct 21, 2024

That sound like a good idea! I will look into it.

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

No branches or pull requests

2 participants