QOwnNotes icon indicating copy to clipboard operation
QOwnNotes copied to clipboard

WIP: Add support for git push on every commit

Open grisuthedragon opened this issue 3 years ago • 18 comments

Since I am using my own git server instead of nextcloud to keep my files in sync, I often forgot to push the changes to my notes' folder. For this reason, I created this patch, which allows performing a git push after each commit. In this way, my remote git repository is kept up to date when using QOwnNotes.

The patch adds an option to the notes folder in order to enable/disable the git push functionallity. This requires the database version of the notesFolder table to be updated to 42.

grisuthedragon avatar Apr 12 '22 11:04 grisuthedragon

As much I would like this to include, I think it still doesn't address the fundamental issue mentioned in https://github.com/pbek/QOwnNotes/issues/2076#issuecomment-803638320 or https://github.com/pbek/QOwnNotes/issues/744#issuecomment-336156850... The part with conflict resolution. I can already see issues like "QOwnNotes isn't pushing my commit, pls fix". 🙈

Do you have a suggestion?

pbek avatar Apr 12 '22 13:04 pbek

I see the basic problem. So the option I could think of would be to build a pull/push around the commit and make some options like "On conflict use mine" "On conflict use theirs" to obtain a default handling of the conflict situation. If none of both is selected and error is raised with the hint, that the conflict has to be resolved by hand. (From my point of view, everybody who is working with git for serious things should be able to resolve a merge conflict.)

So the commit workflow should be

git add -A 
git commit -m "QOwnnotes commit" 
git pull --strategy=<ours|theirs>
git push 

If the remote is used by several people there is a short time window in between, where it could still crash.

grisuthedragon avatar Apr 12 '22 14:04 grisuthedragon

Another issue, especially for new users of QOwnNotes and git, will be how to set a git remote...

pbek avatar Apr 12 '22 14:04 pbek

For the beginning, I would say, they have to do this on the CLI. If the repository is clone, the remote is set any way.

grisuthedragon avatar Apr 12 '22 14:04 grisuthedragon

So the option I could think of would be to build a pull/push around the commit and make some options like "On conflict use mine" "On conflict use theirs" to obtain a default handling of the conflict situation.

That would work... Another option then.

For the beginning, I would say, they have to do this on the CLI. If the repository is clone, the remote is set any way.

Then we need a guide to explain the steps... For example a git.md in https://github.com/pbek/QOwnNotes/tree/develop/webpage/src/getting-started...

pbek avatar Apr 12 '22 14:04 pbek

In order to keep the list of options as short as possible, I would restrict the merge options to "In case of a merge conflict, use the local version." If the box is not checked, git's default behavior is used.

Then I will try to write a git.md file as well.

I changed the PR to "WIP" and try to develop the stuff during the next days.

grisuthedragon avatar Apr 12 '22 14:04 grisuthedragon

I found another problem, which is causes trouble in case of the pulls. The detection if a file was changed on disk does not detect the stuff going on when pulling and thus changes are lost.

So another idea, which may lead to an easier to handle solution. (Regarding where I was coming from, that I work on the notes, close the laptop and then recognized that the stuff was not pushed).

  1. Add a Menu Entry or a Toolbar Button for "Git Pull", which raises an error message in case of a merge conflict.
  2. Do the push on every commit, raising an error message, that a pull is required before.

Does this sound reasonable?

grisuthedragon avatar Apr 12 '22 15:04 grisuthedragon

Seems like there is a reason that tools like https://github.com/muesli/gitomatic/ exist. 😅 I don't think anyone would like a manual pull.... Maybe just force-push (and possibly destroying anything on the remote repository)?

pbek avatar Apr 12 '22 18:04 pbek

I tried a bit how to get a reasonable git workflow integrated, which tries to merge if possible, otherwise throws an error message. In a normal one-person workflow this seems to be reasonable. The only problem I have left now, is that after doing the pull/push, all currently open notes have to be reloaded in case the have been changed by the merge. @pbek Can you help me implementing this?

grisuthedragon avatar Apr 13 '22 07:04 grisuthedragon

all currently open notes have to be reloaded in case the have been changed by the merge.

Doesn't that already work? The note folder should reload automatically if files are changed if you do not actively block that FileWatcher and DirectoryWatcher event in the source code.

pbek avatar Apr 13 '22 11:04 pbek

all currently open notes have to be reloaded in case the have been changed by the merge.

Doesn't that already work? The note folder should reload automatically if files are changed if you do not actively block that FileWatcher and DirectoryWatcher event in the source code.

Unfortunately not. I tried it in the following way. I changed a file at the beginning in the git remote and in the end using Qownnotes. Thus, the merge will be successful. In order to see the change, I have to close the note and open it again.

grisuthedragon avatar Apr 13 '22 11:04 grisuthedragon

Unfortunately not. I tried it in the following way. I changed a file at the beginning in the git remote and in the end using Qownnotes. Thus, the merge will be successful. In order to see the change, I have to close the note and open it again.

...or reload the note folder (see Note menu) Or in code like in MainWindow::on_action_Reload_note_folder_triggered(), but maybe not reload the current note, that might be annoying while you are typing into the note...

pbek avatar Apr 13 '22 11:04 pbek

all currently open notes have to be reloaded in case the have been changed by the merge.

Doesn't that already work? The note folder should reload automatically if files are changed if you do not actively block that FileWatcher and DirectoryWatcher event in the source code.

Unfortunately not. I tried it in the following way. I changed a file at the beginning in the git remote and in the end using Qownnotes. Thus, the merge will be successful. In order to see the change, I have to close the note and open it again.

It seems that I was too fast during testing. Now it works.

grisuthedragon avatar Apr 13 '22 14:04 grisuthedragon

I moved the error and status message to the status bar in the main window. Now it seems to work, at least for my purpose.

grisuthedragon avatar Apr 13 '22 14:04 grisuthedragon

When I activate the "git push checkbox" (with the default settings of 10sec interval) QOwnNotes takes about 19sec to start (instead of 0.1sec). When I start typing (or even if I don't do anything at all) the UI is frozen for a long time, then responds for a sec or so just to be unresponsive again...

I had this issue when an external git push wasn't correctly setup (remote git repository on gitlab.com) and also after it was setup and no error was shown in QOwnNotes. Most of the time I had to kill the QOwnNotes process. I'm not even able to interact with the application after the startup anymore. But the the process never took many CPU cycles.

Everything still works fine when I don't use the "put push" feature.

General Info

Current Date: Do. Apr. 14 12:17:08 2022 Version: 22.4.0 Build date: Apr 14 2022 Build number: 960 Platform: linux Operating System: KDE neon User - 5.24 Build architecture: x86_64 Current architecture: x86_64 Release: Self-build Qt Version (build): 5.15.3 Qt Version (runtime): 5.15.3 Portable mode: no

PS: It should not be possible to enable the "git push" checkbox when "git support" isn't enabled in the settings dialog.

pbek avatar Apr 14 '22 08:04 pbek

the UI is frozen for a long time,

Because process->waitForFinished() is running the process in the main thread to wait for the result.

pbek avatar Apr 14 '22 14:04 pbek

...a QTimer::singleShot around the whole remote git pull/push operation (and being very diligent what gets accessed in that time) should help.

and because the remote git pull/push can take ages there also needs to be some kind of locking so that not multiple git pull/push operations can be active at the same time (and cause havoc on git and DOS the local computer and the server)

pbek avatar Apr 15 '22 04:04 pbek

a QTimer::singleShot around the whole remote git pull/push operation (and being very diligent what gets accessed in that time) should help.

QTimer::singleShot still blocks the UI thread. 😬 seems like QThread needs to be used to run the commit and push methods.

pbek avatar Apr 15 '22 11:04 pbek

I will close this until there is more information.

pbek avatar Oct 11 '22 06:10 pbek