Why does

gt submit

so often give the following error?

ERROR: Branch <branch name> has been updated remotely. Use gt get or gt sync to sync with remote before submitting (or use the --force flag to override this check).

I think Graphite sometimes rebases PRs on the remote. I assume it can happen at any time. Submitting a local branch should not entail a race condition between my local work an Graphite's automatic rebases. I think this is what's happening. On the other hand, if some other team member/local environment pushes an update to the remote we definitely do NOT want to

gt submit --force

. It's mega mega important that when these conflicts arise for legitimate reasons they not be crowded out by noise. Finally, the options when I receive that error message are basically to

gt submit --force

or pull the remote changes onto my local, wiping it. There is a third option that says something like "ignore this and reconcile it yourself". I assume that means some combination of

git pull

and conflict resolution. I'm comfortable with git conflict resolution, but I never know for sure whether my conflict resolution will preserve **graphite**'s state (which is why I do

gt restack

rather than managing my own rebasing). Why is there no option for graphite to pull changes and start the conflict resolution process? Overall, IMO grahpite handles conflict resolution between the remote and the local poorly and I usually just end up backing up my changes, wiping my local changes with the remote version, and then restoring my changes, a huge waste of time. I never had this problem with git/GitHub. Is there any plan to improve Graphite's reconciliation interfaces when the remote and local have diverged? In particular, when they diverge due to remote rebases, I think Graphite should handle them better.

(If applicable) To help us repro, please send the following if you haven't already: - PR links, screenshots, and/or debug output if applicable - Repro steps - Does this happen consistently? Just to you or others on your team also? - Is this a regression? Is the problem new? - If you're having an issue with the CLI, please send us debug logs using

gt feedback --with-debug-context <any message>

In the short term, can you suggest a rebase-based conflict resolution entrypoint in the error message? When

gt restack

has problems, it just recommends a

git rebase

command, which I find helpful - when graphite doesn't bless a git primitive I never know whether it's allowed. I think in this case literally just adding:

Try this:
git fetch origin
git rebase origin/$(gt parent)

might be the correct sequence to trigger git-native merge conflict resolution. I think there's a more explicit

git rebase --onto ...

command that graphite could automatically show, which would be even more useful. As it stands now I feel like Graphite throws me off a cliff when this happens. I can't use the extensive historical git docs because Graphite often gets confused when I use git primitives.