Change:
- job: LinuxAlpine variables: VSCODE_ARCH: x64 <ins> NPM_ARCH: x64 </ins> steps: - template: alpine/product-build-alpine.yml

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: Steps to Reproduce: VS Code, select two files, right click on one of them and "Compare Selected Files" one of the file, observe the other file also get saved, and trigger watchman as a file change. Hi team, we use to monitor file changes on the disk. When using the comparison view functionality provided by vs code, I've verified that editing -saving one file in the comparison view will trigger the compared file also getting saved, which becomes a false signal to watchman that some content has changed for that file. I'm not sure if it's a bug, but it'd be ideal if we can update this behavior and only save the file for the active editor. Thoughts?
Saving both sides is expected when both are dirty, but I see how it maybe confusing when the left hand side is not dirty to save it then.
Yeah, this seems like essentially a race condition. For some context this causes some degree of problem when we build a service/extension that copys the file content from a file to the compared file. And within comparison view, this behavior races with the service which resulted in an error "file content in the disk is newer, overwrite or compare" error. Any thoughts on how to mitigate it?
I think I can see to make a change to not save the left hand side when it is not dirty.

But note that an explicit save triggered by the user will always flush the contents to disk even when the file is not dirty, in other words it would still save the right hand side of the diff editor which we assume to be the "primary" side. This has been the standard behaviour of VS Code for a long time and allows to trigger external file watchers.
I agree with this, but not quite with the part that it always saves the primary/right side of the editor. Why can't just the active (the file the is currently being edited) file be saved? I guess the challenge to even hack around this is that, regardless whether the left or right editor is saved, the actual file i/o is always that the primary/right editor gets saved first, then the left. This makes it hard for anything outside of vscode to actually tell where the change is actually coming from. I can think of maybe one of these two ways to address this: make vs code save the active file first, then the file being compared. or, make vs code only save the active file
but if this change can be made, I think I have a hacky way to workaround this issue. but i'm not sure how helpful it'll be for other users.
I think it needs to work predictably based on the state of the diff editor: both sides dirty: saving saves both sides irrespective where focus is no side is dirty: saving saves only the side that has focus? one side is dirty: what should happen based on focus? Currently it is predictable in a way that saving will always just save both sides, irrespective of dirty state. So if we change that, we should change to a new predictable state. Can you make a suggestion based on this? And as for the order of saves: is that relevant for you as well?
What do you think if we save only the editor that has focus, regardless if it's dirty or not?
I think we cannot do that. First of all, which editor has focus is very subtle. We would see countless bug reports of user complaining that save does not work for not apparent reason. And then we have always had save trigger a save on the right hand side irrespective of focus even before we the support for saving both sides. So you would degrade the experience for existing users. The more I think about it the more I feel the current behaviour is the only consistent one actually.

What exactly is the issue with this behaviour? It is the first time I hear someone complain about it? I wonder if a better solution would be to have a setting that allows you to control if saving a non-dirty file actually touches it to trigger watchers. If we had that, you could disable this behaviour and not get unwanted file watchers triggering for saving non-dirty files even outside of diff editors.
I don't think I agree w/ the rational here. If you have multiple editors open, saving one wouldn't save others. From the code authoring perspective I don't think the comparison view is anything different from seeing the files from separate editors. What makes diff view special that we need to save both of them? I think it's very nuanced here but we have a service that listens for file changes and copies the file from one place to the other. When you have diff view open for the source and sync'ed file, change the source file, and command + s the source file, with the behavior we've discussed in vs code, vs code tries to save the sync'ed file, which oftentimes races with the service that tries to sync the file from the source, resulting an error, something along the line of "file on disk is newer, compare or overwrite".
Decided to push a change to only consider the left hand side of a diff editor for saving when it is dirty. To verify no regressions: compare 2 files that are editable change the left hand side verify you see a dirty editor opening as tab in the background save the diff editor () verify the dirty editor in the background is saved change the right hand side verify the diff editor gets dirty save the diff editor () verify the dirty diff editor is saved change both sides save the diff editor () verify the 2 dirty indicators went away Finally verify this issue in particular: compare 2 editable files take note of the modification timestamp on the file system using OS explorer save the diff editor () verify that the right hand ("primary") side file updated its modification timestamp verify that the left hand ("secondary") side file modification timestamp did not change