Allowing to pull and merge local changes with remote

[jozefkrkoska]

No description provided.

[rehoumir]

There is one issue I found when testing it locally:

1. My object is in sync.
2. I make a local change and push it on remote.
3. I do not commit my push locally.
4. I run pull -r.
5. prd stashes the object. Because it's not in changed files and there is a different timestamp, remote gets applied and then the stash gets replayed (good).
6. The user somehow combines the changes into a single object and commits that.
7. But now, there might be changes that are on remote and that are not there at all!
8. Because the user already committed, we will not ever push the object back on remote (unless some third change is made).

The goal of pull is to be in sync with remote, but here, we are potentially making them de-synced.

[rehoumir]

One idea how to reduce the risk:

• Show the "resolve conflicts in GIT prompt" as now, but also mention that they should type in "push" once done into the CLI.
• The command will not finish after rebase, but will be waiting for that keyword (anything else means the command should finish with an error about "Desynchronised local-remote state" and that they should run push before committing local changes).
• Print the paths of objects where the conflicts need to be resolved (maybe we can run git to tell us which they are - it cannot just be git status, because there might be non-conflicting changes pulled from remote).
• The command will run prd push (via the function, not as subrocess.run). Unless the user screwed up timestamps locally, the command should be able to update everything.
• IMPORTANT: We should not push all changes that are in git status - that might include stashed local changes and new remote changes. We need to only push the files that actually have a conflict.
• After the push, the command should automatically commit changes that had a conflict (not others!) - the user might have local changes they don't want committed, etc., but we should also not show him what he already resolved like this (objects with a conflict will now be in-sync and should not show up on the git index).

Let me know if you can think of an easier approach, or if this is too heavy-handed.

[jozefkrkoska]

I have another possible solution. After a push, there is always a pull afterwards. What about just pulling with -c afterwards, so everything gets commited? But idk if that might break something else...
I will also implement what you proposed.

[jozefkrkoska]

I am not sure if it's a good idea to commit the merged files after push, because it changes the default prd2 push behavior - it pushes them, but lets the user commit the files locally.