git-spice tracks local main instead of origin/main

[jkanywhere]

I would like git-spice to be smarter about comparing to origin/main instead of my local main branch because local main is not always up-to-date.

Very possible I've misconfigured git-spice, or missed an important step of the flow. Advice is appreciated, thank you.

Steps to reproduce:
I'm using GitHub and git-spice 0.19.0.

1. create a stack. For example:

❯ gs log long
  ┏━■ branch-2-bar ◀
  ┃   cbc5e11 fantastic feature (19 hours ago)
┏━┻□ branch-1-foo
┃    a8b8e11 beautiful bugfix(40 minutes ago)
main

2. git checkout branch-2-bar Be on top of the stack
3. Run git fetch to get the latest origin/main. At this point my local main branch is behind origin/main.
4. Run gs stack submit.

Expected behavior:
Pull requests are created for branch-1-foo and branch-2-bar only.

Actual behavior:
git-spice starts to submit changes by describing commits that are already in origin/main but not my local main.

The proposed PR title comes from a commit on origin/main

❯ gs stack submit
Title: thing done and landed by a colleague (#12345)

so does the proposed PR body.

After I edit the proposed title and body then the commits and files changed in the created PR accurately reflects the commits on each branch.

This could therefore be a problem only with the guessed title and body.

[abhinav]

Hey Josh!

You're correct; today git-spice assumes local trunk is authoritative. gs repo sync will make sure main and origin/main are in sync (rebasing any local commits on top of remote).
Some users were able to work around this by setting trunk to origin/main but I added protection against that (#734) because it broke other things. There's also some protection around trunk being too old when initializing (#738).

The immediate workaround is to use gs repo sync instead of git fetch, but I agree this is a workflow that we should try to support:
if a remote is configured, there should be an option of treating that as authoritative instead of the local copy of trunk.

[jkanywhere]

The immediate workaround is to use gs repo sync instead of git fetch

I will teach my fingers the new way. Thanks!