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

Notes/ideas about improving automatic resolution of reddup items #17

Open
joelmccracken opened this issue Aug 27, 2020 · 0 comments
Open

Comments

@joelmccracken
Copy link
Owner

joelmccracken commented Aug 27, 2020

From @Anton-Latukha via gitter chat from another project:

Good project. I looked to find something like that at the time of exactly 2 years ago, because then I found none to suffice requirements - wrote a solution for myself, using the fish shell scripting.
To share the thoughts, basically:

  • There is a function that scans the directory passed to it recursively and finds .autocommit files and checks that directory is in fact a Git repository.
  • reddup has a central configuration, wich is more declarative approach.
  • .autocommit files hold information of how frequently to autocommit. For example, I want to autocommit certain repos that track info (as notes), if I "forgot" to commit available changes for more then two days. Function gathers them in the list.
  • So thre is a list Git repositories, that hold .autocommit files.
  • There is a systemd timer(s), or cron (anacron) daemon(s), that triggers after some requirements. I have a trigger after 10 minutes after startup is done, trigger launches systemd service.
  • Service runs main function, which recurses on the list generated.
  • If .autocommit rule is True - functions autocommit the repo, creating commit with short-iso autocommit message.
    For the reddup tool one can provide the systemd timer trigger and the service. Every user has rights to own systemd space, essentially used adds --user as the first key of all systemd operations, as systemctl --user ..., so every user on the system can run own triggers and services, which you can provide for them.
    Logically follows that in central configuration there should be a selection "what to autocommit", by a presence of the rule "when to autocommit", there also a supplementary rule - "how to autocommit the repo" (including new files, etc.).
    Those are the thoughts on the topic, people are free to bear them also, they should close the circle and as so - bring the hands-free automation of tracking/backup processes, which many probably search for.

So basically it might be nice to have examples related to how to set up systemd, and also incorporate the other features he is referring to (using autocommit rules).

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

1 participant