jhpyle / docassemble

A free, open-source expert system for guided interviews and document assembly, based on Python, YAML, and Markdown.
https://docassemble.org
MIT License
786 stars 255 forks source link

Files revert back to previous commit #198

Closed knod closed 2 years ago

knod commented 5 years ago

It may have been to the previous commit, but it may have been further back. It's happened to me three or four times in the past week.

I'm putting what I know of the problem here now so we can narrow it down more moving forward and figure out the next things to test.

You'd think it wouldn't matter so much, but there are some circumstances that are very frustrating:

  1. You saved changes, but didn't commit them. I think in that case they just disappear, replaced by that older commit.
  2. You don't know it's happened and you edit the files with new changes that you want to keep. Since the file contents have reverted to the previous commit, you'll have a mix of outdated content and new changes. It can be hard to figure out what is what.

Replicating

  1. Save some files.
  2. Go to Packages and select them to be part of the Playground Package.
  3. Save that change.
  4. Confirm that they remain selected after a refresh.
  5. Commit them.
  6. Leave file tabs open.
  7. Do not log out.
  8. Restart browser? Leave the computer asleep for a long time? Have the file 'session' expire (little blue dot appears in the tab)?
  9. You are still logged in.
  10. Possibly just go to an open tab or possibly click on a tab that's not active.
  11. Possibly refresh the page? I don't think I did that with all of them.
  12. Possibly press 'Save' on those pages?
  13. Make a new commit.
  14. Some files will have been reverted back to a previous commit.

Evidence

Because human minds and memories are frail, this is how I confirm when this has happened. When I suspect files have been reverted and then those reversions saved:

  1. Commit to a brand new branch
  2. Go to github and do a pull request from the new branch to the old branch
  3. The diff shows that the changes the new branch implements are actually undoing the changes that were made in the previous commit. Example:
    1. Commit 1 (master): Put the word 'foo' in a file.
    2. Commit 2 (master): Changed 'foo' to 'bar'
    3. Commit 3 (reversion): 'bar' is changed back to 'foo'

I know, it's confusing. I welcome suggestions on how to clarify.

Other things to know

  1. I did not have multiple tabs open for editing the same file.
  2. If you don't open/refresh a file after the reversion happens, it's contents won't be reverted.
  3. Maybe if you don't save the file after opening it, the changes aren't reverted. I'm not sure of that.
  4. Just restarting the browser didn't trigger it. (needs a double check)
  5. Just going to sleep didn't trigger it.

How to get back to the most recent commit

If you haven't yet made any changes that you really want to keep, you can just go to the Packages and pull from the branch that you've been working on. For me it's mostly master.

What to do when you've made some changes you want to keep

  1. Don't open or activate any more tabs.
  2. Before hitting save or refreshing pages you have interacted with, copy the file contents. Refresh, then paste what you had copied, then save. I think it only sometimes works. I think sometimes the edits you made are already gone. Maybe it's because the files were saved but not committed, were edited but not saved (pretty sure this is not the case because I save religiously), or something else.
  3. Commit to a brand new branch.
  4. Compare that branch to the branch you were just on in github.
  5. Try to figure which changes you want to keep from both branches.
  6. Make everything the way you want it and commit again
jhpyle commented 5 years ago

Before making a commit, you should close all other playground tabs in your browser on all of your devices. When you make a commit, the files in the Playground can change. This is because the "Commit" button actually does a merge behind the scenes. You don't want to have versions of files "cached" in your browser, because then when you press Save you may be overwriting changes with out of date versions.

knod commented 5 years ago

That's good advice, but I don't think it applies here. In my case, all of the files were up to date already.

knod commented 5 years ago

Just to add some data, a possibly related behavior:

  1. Opened a file
  2. Edited it
  3. Saved it
  4. Waited a long time? No commits.
  5. Refreshed the page
  6. The file on the page doesn't include my saved changes. It reverted back to how it was before it was saved.

So this doesn't go back to a commit previous to the current commit, but it does go back to the state of the file at the most recent commit instead of to the file as it was saved.

[Edit: To be clear, there were absolutely no commits made at any point in here.]

knod commented 5 years ago

This time it happened without any long waiting in between. I happened just after a commit. The file looked up to date, I made a commit, the file's contents were no longer up to date. I don't think I even refreshed the window, but when I did refresh, the code was still wrong. I was lucky I noticed it. I pulled to get the updated code back.

Next time I'll close my tabs and re-open them. Is there anything I can log to find out what's going on?

jhpyle commented 5 years ago

The docassemble.log file logs what the various git commands are doing.

You should always close all other Playground-related tabs before pressing the Commit button. Behind the scenes, the Playground files are changed according to what is required by the process of merging your edits relative to the latest pull into the current state of the selected branch. The Commit button process ends with a pull, which overwrites the contents of files in the Playground. The commit that was just committed thus becomes the "latest pull."

knod commented 5 years ago

The latest commit isn't what's in the files, though. That's what I'm finding confusing. The commit before the latest commit is what's in the files that get changed.

knod commented 5 years ago

New experience that I think may have had nothing to do with commits:

  1. Created new file.
  2. Put stuff in it.
  3. Saved new file. (Let's call this version of the file State 1)
  4. Edited file.
  5. Saved file. (Let's call this version of the file State 2)
  6. Committed but forgot to include new file.
  7. Pulled.
  8. Restarted computer.
  9. Opened that same file.
  10. File was in State 1 again. All work from State 2 was lost.

Nothing about the commit should have affected anything. So maybe this has nothing to do with the commits. Could it be something with cookies? Local storage?

knod commented 5 years ago

Since the commit dealing with the cache I haven't noticed any issues. This may have been caused by a specific plugin and I'm grateful that I'm able to use both Docassemble and my plugins. Thank you!

knod commented 5 years ago

Sorry, but this happened again. I'm not sure if I've just been missing it happening or if something was different this time. This was a situation where I'd restarted my browser, restoring all tabs.

This time it was even more pronounced because when I downloaded the text of the interview, it was the text from an older version. I pulled the master branch and it took 5 minutes or so for the interview page to get back to normal.

I'm not sure if it's related, but now when I try to download the text it's missing parts of the interview text. Specifically, a piece of text that I can currently visually see on the interview. I haven't gone through the whole text, so I'm not sure what all is missing.

knod commented 5 years ago

I'll try disabling the plugin, of course, I'm just updating on the current state of the fix.