There's a common problem if you use the LFS locking mode with more than one person. Because Submit automatically pushes so that it can unlock, if that push fails you're left in a state where you need to resolve it yourself. This means:
Pull
Push
Manually unlock (because Push doesn't do it - I may submit another PR for that)
This is awkward when most of the time the changes are unrelated, git just won't let you push. And since Unlock isn't exposed in UE4 you either have to do it manually, or know that Revert will do it (even though you haven't got any local changes).
In 99% of cases where locking is applied, you could just auto-pull to resolve then try again. So that's what this PR does. In the case of a failed pull, this change:
Checks whether the failure was a non-fast forward error
If so, it checks whether there are any other modifications, and stashes if needed
Performs a pull --rebase (since that's the default in the Pull menu)
Re-tries the push
Applies the stash again (even in the case of further push failure)
This is a big QoL improvement for us, hope you like it.
SRombauts
commented
4 years ago
There's a common problem if you use the LFS locking mode with more than one person. Because Submit automatically pushes so that it can unlock, if that push fails you're left in a state where you need to resolve it yourself. This means:
This is awkward when most of the time the changes are unrelated, git just won't let you push. And since Unlock isn't exposed in UE4 you either have to do it manually, or know that Revert will do it (even though you haven't got any local changes).
In 99% of cases where locking is applied, you could just auto-pull to resolve then try again. So that's what this PR does. In the case of a failed pull, this change:
This is a big QoL improvement for us, hope you like it.