You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It always seemed wrong to me that the Git working directory is placed in public storage.
The other day, my Pixel suggested I clean up some "unused files" in my public storage, and because I was not paying proper attention, I ended up trashing some files from Orgzy's .git directory. (I then tried to restore them from the trashbin, but my workdir was still broken for some reason.)
This is just one of the issues with storing the Git dir in public. I have also seen multiple bugs related to directory selection/creation and storage permissions (e.g. #24 (comment) and #916). The fact that the user needs to create an empty directory before adding a Git repo is also pretty bad UX, in my opinion.
I'm thinking this issue could be a forum for discussing the pros and cons of private vs public storage for this directory.
I'll start by quoting an old comment by @IvanMalison:
@amberin, yes, conflict resolution DOES likely happen on another system, but even in that case, we need to be able to manipulate the raw git repository, because when there IS a conflict, we will need to put the changes from orgzly somewhere back out there (i.e. on a branch that is not matched up with master). Then those conflicts need to be resolved and synced back in to the main master branch.
I suppose that we could have orgzly simply push its view of master to another branch, while leaving its view of the world as the local master, but I still think there is value to exposing the underlying git repository to the user just in case things get kind of hairy.
(Since then, this has more or less been implemented; we push "conflict branches" to remote, and conflicts are expected to be resolved on another device. We then automatically return to the main branch as soon as possible.)
I can see the value in being able to manually poke around in the Git working directory using some Git app on the phone. However, I have personally never gone to the trouble of doing so, despite many hours of Orgzly development which has put my phone in various weird states. And as my recent experience shows, there is a flipside to this ability. In my case, I was indeed unable to restore my .git dir to a working condition despite having access to all the files and tools. (This may of course be attributed to my own stupidity, but unfortunately it is probably not completely unparalleled.)
The text was updated successfully, but these errors were encountered:
If this is ever implemented, one might add a button in the RepoAcitivy for copying the .git and working directories to public storage, so that its contents can easily be salvaged if the remote is somehow lost.
It always seemed wrong to me that the Git working directory is placed in public storage.
The other day, my Pixel suggested I clean up some "unused files" in my public storage, and because I was not paying proper attention, I ended up trashing some files from Orgzy's .git directory. (I then tried to restore them from the trashbin, but my workdir was still broken for some reason.)
This is just one of the issues with storing the Git dir in public. I have also seen multiple bugs related to directory selection/creation and storage permissions (e.g. #24 (comment) and #916). The fact that the user needs to create an empty directory before adding a Git repo is also pretty bad UX, in my opinion.
I'm thinking this issue could be a forum for discussing the pros and cons of private vs public storage for this directory.
I'll start by quoting an old comment by @IvanMalison:
(Since then, this has more or less been implemented; we push "conflict branches" to remote, and conflicts are expected to be resolved on another device. We then automatically return to the main branch as soon as possible.)
I can see the value in being able to manually poke around in the Git working directory using some Git app on the phone. However, I have personally never gone to the trouble of doing so, despite many hours of Orgzly development which has put my phone in various weird states. And as my recent experience shows, there is a flipside to this ability. In my case, I was indeed unable to restore my .git dir to a working condition despite having access to all the files and tools. (This may of course be attributed to my own stupidity, but unfortunately it is probably not completely unparalleled.)
The text was updated successfully, but these errors were encountered: