Unexpected modified/outdated/deleted unstaged files showing up in the Git Staging view

[chrispitude]

Hi everyone,

We have noticed that occasionally, unexpected modified, outdated, or deleted files show up in the unstaged (top) section of the Git Staging view.

For example, earlier this week a writer contacted me to ask about such unexpected files. I found the following:

• Some files were listed as deleted.
• Some files were listed as modified, with contents from earlier in the repo's history.

None of the files were related to content that the writer was working on. And strangely, the changes were not time-consistent with each other. For example, the deleted files were Oxygen configuration files that have been in our environment for 2+ years. But the outdated files had content from a few months ago. So even if JGit checked out files from some wrong SHA, there was no point in time where the deletions and outdated content existed together.

For future occurrences, I will try to investigate more deeply and share the details here. So far, I have no reproducible way to file an issue for this, but hopefully over time I can get this figured out.

Has anyone else encountered unexpected unstaged files showing up?

[xephon]

Hi Chris, yes, but I also could not reproduce it manually. It rarely happens.

[chrispitude]

Hi Stefan,

Thanks for sharing your experiences! It is rare for me personally too. But across our team of 50+ writers, it's happened about a dozen times. And I am concerned that a writer's in-progress unstaged files could be overwritten by this behavior (which thankfully hasn't happened yet).

I have asked my team to contact me as soon as they notice unexpected files in the unstaged files view, and to make a note of exactly what steps led up to their appearance. I will share my findings here, of course.

[alex_jitianu]

Hi,

If you happen to come across this situation again, please try to move focus to another application and then return to Oxygen. On such event we drop internal caches and we recompute the state of the repository. I would be interested to see if it has something to do with this.

Best regards,
Alex

[chrispitude]

Hi Alex,

I will certainly try this next time and share the results!

And thanks as always for all the effort put into the Git add-on. It is an essential part of our success with the Oxygen/DITA/Git combination. We have multiple Git release branches going in parallel, with weekly cascading merges to propagate changes in any release branch forward to later release branches. It has been amazing to see everything come together and tame the complexity so well.

[chrispitude]

This issue occurred for one of our writers. The sequence of actions was as follows:

• She committed three new files.
• She attempted to push the commit, but was informed that upstream commits needed to be pulled first.
• When she did a pull-rebase, a conflict dialog popped up. When she chose to continue with conflict resolution, the Git add-on became unresponsive.
• Eventually she had to exit and restart Oxygen.
• Now, the Git Staging view indicated an in-progress rebase.
• The Unstaged files list showed her three committed files as deleted, and all recent upstream changes in their place.
• There was an orphaned "index.lock" file in the .git directory.

Here you can see the unpushed commit and the rebase-in-progress:

unstaged1.png (8.85 KiB) Viewed 1898 times

Here you can see the three deleted files in the committed-but-not-pushed local commit:

unstaged2.png (14.12 KiB) Viewed 1898 times

The unstaged files survived multiple focus changes, tool restarts, and laptop restarts.

When I deleted the orphaned lock file, I was able to abort the rebase and the unstaged list became empty. When I attempted the pull-rebase again, it completed successfully with no conflicts or messages, and I was able to successfully push her commit of the three new files.

This is strange -- why was there a conflict the first time, but not this time? And, there should not have been a conflict with her three files - the three files in her commit were new and could not conflict with anything.

So my guess is that JGit somehow got itself into a confused state during the pull-rebase where it saw an incorrect conflict, then crashed, leading the files in the "upstream-only-without-local-commit" state.

As a reminder, I did not start this discussion to demand immediate fixes. I recognize that this issue is nearly impossible to reproduce on demand, and is quite possibly not even in code written by Syncro Soft. I am primarily looking to share my experiences over time and perhaps converge to a better understanding (and hopefully then a resolution) of the problem.

[chrispitude]

This week, a writer recently had to do some work in an Oxygen/Git project directory that she had not worked in since 2020. The current (last-used) and new (desired) branches in this directory were as follows:

Current branch: "master"
New branch: "release/T-2022.09"

When she ran Oxygen in this directory, the Git Staging view indicated unpulled commits in the current "master" branch (because her last pull was in October 2020) and the unstaged/staged file lists were empty.

She wanted to work in "release/T-2022.09", so she went to the Git Branch Manager and double-clicked the upstream "release/T-2022.09" branch to pull it locally. After some time, the unstaged files list became populated with many files, and the current branch still showed "master" instead of the desired "release/T-2022.09" branch:

image.png (28.47 KiB) Viewed 1836 times

At this point, she archived her Oxygen/Git directory and sent it to me for analysis.

There is no lock file in the .git directory. The files in the repository are a mix of "master" and "release/T-2022.09" revisions. In fact, every file matched either its "master" or "release/T-2022.09" branch tip state; no files had content in some other state. So, my guess is that the branch pull operation crashed/stopped while updating the files to "release/T-2022.09", in some way that didn't leave the repository locked, so that the repository now thinks that all the "release/T-2022.09"-updated files now have unstaged changes relative to "master".

If I find time, I might try to recreate this by discarding the changes, making a copy of that directory as my starting point, then repeatedly trying to pull the new branch to see if I can reproduce the behavior.

[alex_jitianu]

Hi Chris,

We've tried to reproduce this on our side, but without success. In the screenshot, I see that there is an error reported in the bottom status area of the view, "Cannot reach remote repository". If you hover it, it should give more details about the problem. Anyway, that status area is for errors that appear during our automatic checks, like for example when we fetch remote data on a thread. If the checkout operation were to fail, a popup error dialog would have been presented. But perhaps this is a dead end, perhaps the screenshot is from your machine, when you inspected the working copy.

I've double checked and we catch every exception during the checkout operation and present it to the user in a popup dialog.

Best regards,
Alex