git push -r moves all the older files of a drive into 'trash'
emaxerrno opened this issue · comments
[agallego][ag:~/gdrive]
$ drive push -h
Usage of drive push:
-hidden=false: allows syncing of hidden paths
-no-prompt=false: shows no prompt before applying the push action
-r=true: performs the push action recursively
The command does not mention moving all existing files to the 'trash' directory in google drive. Thank god my old files were moved to trash instead of permanent deletion.
The result fater this was only the directory that i push'ed -r . The expectred result is the additive effect of the directory I pushed recursively + old files.
Too bad to hear about that. Just a quick tip, probably do a drive pull on first init to get your content registered locally just in case you want to push later. Otherwise, 'push'-ing requests that your Google drive be mirrored to the local drive directory. The absence of a file locally during a push is telling drive to delete it if present upstream.
Also a '-' suffix before a change prompt is telling you that deletion will be performed for that item wherever upstream is.
Hope this can help for starters.
Just discovered this too. Wasn't using the recursive option and it still removed files in the destination.
Also found that a gdrive pull will delete local files that do not exist remotely.
At the moment, it seems quite dangerous using push or pull on a whole folder.
Hey folks, I have started a wiki at https://github.com/rakyll/drive/wiki to hopefully address such issues and help users understand the usage and behaviour of drive, as well as answer some commonly raised issues/questions. For now it is a rough wiki but will be updating it over the course of the week.
Cheers!
Thanks for putting up the wiki. It doesn't quite go far enough in explaining that files will be deleted in the destination. I think it covers the simple use case quite well, where we do an initial pull and then follow it up with a push or pull to sync additional content.
I think one of the issues is that using verbs like push and pull one expects it to behave a bit more like git or even rsync but it's behaviour is quite different.
For example, if I do an initial pull and then add a local file (testlocal.txt) and then a colleague adds a file to the same folder (testremote.txt) I am stuck. If I pull from the remote, it will delete my new local file (testlocal.txt). If I push to the remote it will delete the new remote file (testremote.txt).
I understand that I can push the specific file and that is a reasonable thing to say for this example but what if hundreds of files have been changed?
I guess if this is by design, it needs to be spelled out more explicitly in the wiki and a particular warning for those using -no-prompt.
I would suggest that this should not be the intended design. If we were to behave the same as git or rsync a local deletion would lead to a remote deletion and vice versa, but we should not delete files simply because they do not exist in our source. With rsync I believe you can turn on the feature to delete files not in the source.
What do you think?
@sudsy thank you for your great explanation! I see what you are saying and will make the suggested amends to the wiki.
The case in which multiple versions of the file are present in different places suggests to me a version control system for correctness. This would diverge from the current simple behaviour of clobbering on conflict. However, I totally agree with the goals and effects of the suggested behaviour. Despite requiring a design overhaul, in my opinion it will make the product better and safer if we head in that direction.
However, I'll let @rakyll weigh in and make the decisions concerning design.
Let me know what your thoughts are.
@sudsy I took heed of your suggestion and implemented this feature. I actually find it quite useful as well. It will be useable both for pull and push. It is at: https://github.com/odeke-em/drive
Thank you and please let me know of any more thoughts and suggestions!
That's a simple way to solve the problem.
I will check it next time I get a chance.
@odeke-em, am I correct that the feature your're describing is a -no-clobber switch?