Explore optimal Web IDE flow for commiting to branch that already has a newer commit
@smcgivern brought up the following scenario in https://gitlab.com/gitlab-org/gitlab-ce/issues/59023.
- Create a file.
- Open it in the web IDE.
- Make a change but don't commit it.
- Elsewhere, make a change to a different part of the file, on the same branch.
The next step would currently look like this:
@pslaughter mentioned that there might be another option to solve this, which resembles git rebase
:
- If no conflicts, I'm good to go (I'd probably like to run my tests again though).
- If conflicts, I need to resolve manually first (and should definitely run my tests again).
In the Web IDE, this workflow slightly differs because we combine git commit && git push
. So option 1 would look more like git stash && git pull && git stash pop
(which may or may not cause conflicts). Most of this can be done, because now we have a way to capture our Web IDE changes
We should explore which option(s) we provide the user with and how these flows would look like in detail.