Can not discard changes on Source Control

[spieriArtera]

We started noticing the following issue since updating to version 3.0.0, still having the issue on 3.0.1 :
If we run Import and Compile to compile all the source code, for example after cloning a repository or switching branch, many unchanged source codes are marked as changed and added to the changes list on Source Control on VS Code. This was happening also before version 3.0.0, but in the past we just had to select Discard All Changes on Source Control and the unchanged files were removed. Now after discarding the changes the code is recompiled and readded to Source Control, leaving us on a loop. The only workaround to remove them is to disable Compile On Save, Discard All Changes, and then re enable Compile On Save. Has something changed on the way Compile On Save works? What is the logic that adds unchanged files to the Changes list on Source Control?

[isc-bsaviano]

Hi @spieriArtera, this is a consequence of the client-side editing overhaul that was introduced for 3.0.0. Here's an except from the CHANGELOG:

Automatically sync all file changes, creations and deletions in client-side workspace folders with the connected server. This is controlled by the new objectscript.syncLocalChanges setting, which has three possible values: "all" (automatically sync all file events), "vscodeOnly" (only automatically sync file events triggered by user actions in VS Code), and "off" (don't automatically sync any changes). This new setting replaces the objectscript.importOnSave setting. If objectscript.importOnSave was set to false, the extension will set objectscript.syncLocalChanges to "off" upon activation so no user migration is required.

What's happening in your case is that VS Code is syncing the file change event caused by the git discard, and the round-trip with the server is causing a diff because the class is not in the "canonical" format. The text of a class is not actually stored in the database. It's serialized into a global, and then deserialized again whenever the text is requested. This round-tripping will normalize the class definition text. For example, comments that aren't descriptions (triple slash before a class member) have newlines added between them and keyword names are changed to the canonical case (abstract -> Abstract). This is unavoidable, and is not unique to VS Code. This would happen if you edited the classes using Studio, or imported and re-exported them using the %SYSTEM.OBJ class.

Assuming my assumptions are correct, I think you should round-trip all of your classes through IRIS and collect all of these formatting-related diffs into a single commit. This will prevent confusion related to this in the future.

[spieriArtera]

Hi @isc-bsaviano , if you assumption is correct, wouldn't I see the formatting changes on VS Code? The code looks identical on the Working Tree.

[isc-bsaviano]

Do you mind taking a screenshot of the diff? You can send me a DM on the Developer Community if you don't want to share your code publicly. It's possible that the diff is only trailing whitespace. Even if it's not just whitespace, it shouldn't be any functional changes.

[spieriArtera]

Unfortunately I can not share our code here or on developer community. Should I open a WRC instead? I can share it through that channel

[isc-bsaviano]

I meant you can send me a direct message via the Developer Community but opening a WRC case works as well. What I need to see the diff in the working tree. Then I can explain what changed.

[isc-bsaviano]

Hi @spieriArtera, I reviewed the images you shared with the WRC. I am also not seeing what the diff is. Is there just different whitespace in the ROUTINE line? Do you have a different git client tool ou can open like GitHub Desktop that might show the diff more clearly? For the class I don't see anything at all. Could it be line-ending issues? Our extensions always export using LF, even on Windows. That is not new behavior though.

[spieriArtera]

@isc-bsaviano I installed GitHub Desktop and I found the following about the 179 files marked as changed:

• 14 files are shown as "No content changes found"
• The remaining 165 files are shown as "This diff contains a change in line endings from 'LF' to 'CRLF'

[isc-bsaviano]

Thanks for the update. I am not sure what the 14 "no content changes found" changes are. I didn't think GitHub tracked changes that didn't affect content. The other 165 are confusing. This extension always exports to the file system using LF endings. Do you have any settings at the git level that could be changing these? https://docs.github.com/en/get-started/git-basics/configuring-git-to-handle-line-endings

[ChrisJMarais]

Hi @isc-bsaviano , we have found the same issue. I will explain some of our process maybe it can be of help finding a solution.

We create a branch from our main branch, using VSCode and check out to it
we do the code change and commit the change
we create a merge request (we use GitLab)
once done we switch back to the main branch and pull to get the latest changes of all other devs
at this point the files we changed are flagged as changed with no change in the file content
we have found that staging these "ghost changes" removes them from the list
but it is frustrating to have to do this each time

What i have noticed and i think this is what you said in your initial response, when switching back to the main branch the changed files "revert" to the state before the change, this then triggers a compile to IRIS (which i am certain was not the case in the past, or is just did not notice), after this compile on IRIS the files appear as changed. in the tracking list.

[isc-bsaviano]

What i have noticed and i think this is what you said in your initial response, when switching back to the main branch the changed files "revert" to the state before the change, this then triggers a compile to IRIS (which i am certain was not the case in the past, or is just did not notice), after this compile on IRIS the files appear as changed. in the tracking list.

Yes, this is new with version 3. However, the "round-tripping" with the server that I think is producing the changes has always existed. The only difference is that all file changes are now synced automatically, rather than needing to be manually imported. Are your "ghost changes" line ending ones, or something else? Have you seen this behavior using version 2.x when manually importing files after changing your git branch?

[ChrisJMarais]

What i have noticed and i think this is what you said in your initial response, when switching back to the main branch the changed files "revert" to the state before the change, this then triggers a compile to IRIS (which i am certain was not the case in the past, or is just did not notice), after this compile on IRIS the files appear as changed. in the tracking list.

Yes, this is new with version 3. However, the "round-tripping" with the server that I think is producing the changes has always existed. The only difference is that all file changes are now synced automatically, rather than needing to be manually imported. Are your "ghost changes" line ending ones, or something else? Have you seen this behavior using version 2.x when manually importing files after changing your git branch?

No we have not seen this in 2.x after manual imports. I am trying to find out if it may be line endings that's causing this.

It does look like line endings, but we have nothing set in git to change it.

I am willing to let you connect to me and view the files, and see the behavior first hand.

[isc-bsaviano]

@ChrisJMarais I would expect you to have seen this behavior in version 2.x when you did a manual import. The code that performs the import, compile, and re-export is the same. The only change is when it is triggered (manually or automatic).

[spieriArtera]

@isc-bsaviano I was able to spend more time on testing and I found the following:

• Original files on our repositories have line ending CRLF. We use windows for our development machines.
• Up to ObjectScript extension version 2.12.5 running Import and Compile was leaving CRLF on the files.
• From version 2.12.6 to 2.12.10 included running Import and Compile automatically converts the files from CRLF to LF. It is possible to Discard Changes on VS Code to ignore these files.
• From version 3.0.0 running Import and Compile still automatically converts the files from CRLF to LF, but it is not possible to Discard Changes on VS Code as the files are immediately recompiled and re added to the Changes list.
  Based on the above, is this expected behavior? What is your recommendation for working on our repositories moving forward?

[isc-bsaviano]

@spieriArtera Thanks for doing that research. I was mistaken about when the LF behavior was introduced, but it is now called out in our documentation. Yes, this is the expected behavior. My recommendation is to configure git to be less sensitive to line endings. I think the .gitattributes approach seems most promising. This should prevent line ending diff issues in the future, even if you onboard devs who don't use windows in the future. I will investigate having this extension use CRLF when on windows.

[isc-bsaviano]

Closing because a product change isn't required