Problem description: When tmgit.sh is ran with push-remote argument, the entire system is ran twice.

Possible suggestions:

1. make an exit after running the commits for the first time
2. push-remote should just push to the remote repos, without running anything else

There's a bug on line 45, which prevents the script from running. It's a typo:

            export GIT_WORK_TRSAIU github.com/elisboa/linux-time.machine.sh - só baixar que já tá atualizadoEE="${argument}"

push-remote and custom directory both use the first argument "$1", so it's not possible to use them together.

There should be an option in which tags are used instead of branches (or maybe both?), to make it easier to use in certain environments where there may be write access conflicts

Originally this project only versions what you explicitly and manually add. In some cases, the desired behavior is the exact opposite of it: version absolutely everything all the time inside a directory.

So, a "version-all" mode should always add and version any newly added files to the directory.

version-all parameter is buggy

Instead of automatically version all changes, a "mirror-mode" should be created to do exactly the inverse: preserve the last commit from the last branch.

Since this time machine automatically commits changes, there should be a verbose mode showing a "diff" of what has changed.

Hoje o código de erro é contado manualmente. Isto é um problema, pois caso uma funcionalidade seja inserida no meio do código já existente, toda a ordem dos códigos de erro deverá ser alterada.

Um contador automático de código de erro deverá ser inserido, de maneira a permitir um controle melhor da parte do programa onde o erro ocorreu.

The .dotfiles dir was used as a test and ended up being used until today. So, it would be better to use .tmgit instead of a generic name like .dotfiles.

However, we should check if there is a recommend way to migrate all existing data: if by moving the directory or if by using git init.

This feature should look for the latest stable tagged release and automatically update it when run. If a configuration file is used, it could be toggled. Before that, it should be a parameter passed when running tmgit.sh

I believe that to facilitate the configuration of the time machine a wizars-style configurator can be created. Something like this:

time-machine configure-folder

1. Set the folder to versioning:
   /etc

2. Choose the time to backup:
   -> Peer day
   -> Peer hour
   -> Custom (crontab format)

3. Occurrence of backup (per day or our previous select):
   -> The answer here is going to be every x days or hours.

And for change settings for a folder that is already sync in time machine can be something like:

time-machine reconfigure-folder

1. Select the folder to reconfigure:
   -> List all the folder using time machine.

2. Choose the time to backup:
   -> Peer day
   -> Peer hour
   -> Custom (crontab format)

3. Occurrence of backup (per day or our previous select):
   -> The answer here is going to be every x days or hours.

Today, the project uses it's own variables, but it could use git already known variables, such as:

• $GIT_BIN
• $TMGIT_WORK_DIR

It should use the following git vars:

• $GIT_DIR
• $GIT_WORK_TREE

and these adittional others as well:

• $GIT_COMMITTER_NAME
• $GIT_COMMITTER_EMAIL

When ran for the first time, tmgit.sh does not create a .gitignore file. It's very important, since tmgit must not add any files automatically when running via cron.

Vamos implantar um --version no tmgit

Yeahhh!