[Bug] `yarsync push` overwrite uncommitted modified files on the remote about yarsync

[ynikitenko]

Hey @r888800009 , thanks for your pull request and bug report.

yarsync tests that there are no uncommitted changes in the local repository.
I can't see any way of testing that for the remote repository.
The way I do it is to use yarsync -n push <remote>. -n is dry run and it will show you the transferred data (without making changes).

Otherwise seeing "uncommitted changes" on the remote would mean to compare (push data) between two remote folders. Do you have an idea on how it could be implemented?.. With rsync it is not possible, unfortunately.

[r888800009]

Thanks for your reply, I have some ideas to discuss.

Run local test on the remote server

The first idea, if we expect remote to also install yarsync, and your previous consideration is traffic overhead

There is a hacky way to use --rsync-path to run local test on the remote server, but it is only for ssh connections and does not support rsync://host (rsyncd)

For example, we can run sleep on the remote server with --rsync-path

rsync --rsync-path 'sleep 10 && rsync' remote_host:/

One possible solution is to use the rsync error message to detect whether the local test was successful.

rsync  --rsync-path 'sleep 1 && ls / && rsync' remote_host:/temp -vvvv

We can compare the difference between these two outputs

In this case, it would be better to use the ssh command to avoid hacky code. The disadvantage is assumed the remote repo user uses rsync through ssh.

Dry run as default behavior

Another idea is to run dry-run checking by default when remote push, and the user can set the configuration like config.ini to turn off checking.

This may be useful for new users to avoid accidental overwriting.

If we always run --dry-run first, why not just let it run automatically?

Bare Repository

There is also something like git bare repository, which is divided into multiple repo, one is bare for sync between computers, but I have not tried it with yarsync. If it is a possible solution, maybe users can refer to it.

[ynikitenko]

Thanks for the ideas. They are all rather nice.

Run local test on the remote server

Yes, this should work. Since rsync (and servers) are mostly used by (use) Linux, ssh should also be present in most cases.

ssh <my_server> 'cd <my_repo_path>; yarsync status'

shall print the status.
The downside: (as in git), it doesn't give an error code if something was changed.
I'm not sure one should rely solely on the text output (for a human it's easy to make a mistake).

Dry run as default behavior

Yes, this might be useful.
I would add an option -i, so that it first runs -n, then asks whether the user wants to continue.
Then again, the problem of the reliance upon the user stays.

Bare Repository

There is a kind of a "bare" repository (with detached working and configuration directories), but it is different.
However, when you don't work on a server, you simply don't change the working directory. So you either need a non-bare repository there, or you can go with a simple repo (just don't change it directly).

There are indeed several options to deal with this problem, that's why I'm not sure yet which one to apply. In general yes, it would be good (namely safe) to test for uncommitted changes.

For me, I try to always commit my changes. Also, the files in yarsync repositories are usually not crucial for me (and if they are, I carefully look at the results of dry run - and I synchronise important repositories rarely; I don't update them often).

What is your situation (working routine)? What kind of files do you use? Do you really use a server and add files there? Maybe a better solution exists.