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

Git sync should use private storage for workdir #941

Open
amberin opened this issue Jun 5, 2022 · 2 comments
Open

Git sync should use private storage for workdir #941

amberin opened this issue Jun 5, 2022 · 2 comments

Comments

@amberin
Copy link
Contributor

amberin commented Jun 5, 2022

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.

Originally posted by @IvanMalison in #543 (comment)

(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.)

@ParetoOptimalDev
Copy link

ParetoOptimalDev commented Sep 26, 2022

clean up some "unused files"

Is there a way to tell Android the orgzly git directory is not eligible for this? A denylist of some sort?

Related:

@amberin
Copy link
Contributor Author

amberin commented Dec 30, 2022

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.

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

2 participants