Skip to content

Conversation

@Damon3000s
Copy link
Contributor

A common situation we have been encountering is pull requests that include intended changes (accidental, not relevant to the PR, etc) and we request that they be reverted before being merged. The only way to ensure the files were removed from the PR is to ensure the uasset files were binary equal and to do that we needed to download the files from the status branch directly, replace them on disk and then commit the new (reverted) file. This was a cumbersome problem and sometimes a tad daunting for team members who were less comfortable browsing branches and downloading files.

The solution we came up with for this problem is to add a new context menu option that will revert the selected files to be a binary equal to what they are in the status branch. As you can see by the commit history this is something we tried to do on and off for a while (competing priorities) but finished and rolled out to the team at the end of August (~2 months ago from now).

Several important things to note about this change

  • World assets (Maps) are excluded because the way UE handles reloading maps is problematic and we wanted to sidestep the issue as much as we can. Almost every other asset in UE can be reloaded and display the new version but maps don't and will continue to show the in-memory representation even if the file underneath has changed. This can lead to data loss if the in-memory file is saved again which will stomp the on-disk change. By not allowing Revert To Status Branch on World asset types we sidestep this potential issue.
  • We initially hoped to make it so that if the Revert To Status Branch action failed that it would then run a regular Revert on all of the selected files but that was dropped after we encountered issues getting it working, and we determined it wasn't worth the additional time investment to get it working. In a way it is better to not perform additional actions after the first action failed so that the user has to figure out what went wrong etc. In our use cases we are only reverting one or two files at a time so it isn't a huge load, and errors are the edge case.
  • We took the easy way out for the confirmation and used a simple "Are you sure" message box instead of trying to do something more complex like the Revert confirmation box which displays a list of selected files. This was a time saving measure.

Darcy3000s and others added 30 commits April 10, 2025 11:34
…ou to "Revert to status branch" (Rollback to Origin) - notably this doesn't actually perform any reverts, it just pulls the latest version of that file from main into your branch
…nly sync files which are actually different - bail if we try to sync a file that we don't have to ability to checkout (It's locked by somebody else or changed in a branch other than status branch). Don't try to checkout files which are already checked out
The issue is that paths are in different formats and comparisons don't work (see comments). This works for the base game but requires more testing for plugin content. Matt has also recommended to look into "CreateStandardFilename" and "MakeStandardFilename" as a better alternative, but I want to get this "working" version in first.
Converting DiffResults to absolute paths is easier than converting absolute paths to git repo relative paths. Less code, less problems.
This will cause the file to be unlinked, reloaded and relinked. This way Unreal won't know the file has changed and stomp it.
The option doesn't work for maps, so better to not show it.

It should work for maps that are not One Actor Per File, if the correct options are passed to the reload function, but I haven't gone through the work to attempt to detect that situation.
Also log the operation errors
Instead of trying to revert everything that was selected, only try to revert what we tried to sync to status branch
Updated StringId and category
If FilesToSync is no longer a larger list that is stripped then the responsibility is clearer. FilesToDiff is the full list and the value we get back from the git operation is the subset of files we want to operate on (FilesToSync)
It wasn't working and decided it is more effort and risk than it is worth. If the command fails it is better to get the user to inspect the contents before decidding how to progress.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants