Challenges with collaborative usage across local instances

[ArpanSriv]

When a collaborator clones the repository, their local instance does not include the necessary git-spice configuration (e.g., branch stacks stored in .git). As a result, anyone else apart from me is unable to use git-spice commands to manage my stack without manually initializing or recreating the configuration.

Example

I was using gs to manage a stack:

A colleague resolved a merge conflict on a PR with the trunk branch and pushed the changes. However, they couldn’t use gs usr to restack the dependent pull requests due to the absence of the git-spice configuration in their local instance. The colleague eventually merged the PR manually.

When I pulled the changes and ran gs repo sync, it got stuck, repeatedly prompting me to rebase the same commit. I had to:

• untrack all branches.
• Perform a git pull.
• track all branches in the exact same order.

This situation has occurred twice, so I can provide a reproducer if required.

Issues

• gs repo sync did not work as expected and failed to recover the branch stack properly.
• gs did not work on my colleague's local instance because their configuration was not initialized. (I’m not sure if this is feasible given the current storage mechanism in .git.)

---

That said, good stuff on git-spice btw! It has become a daily driver :)

[messense]

I'm also experienced difficulties when working on the same PR across multiple machines, like sometimes I would push a branch to remote without using gs branch submit then pull it on another machine, make some changes, run gs branch track and gs ss it detects that there is already a branch with the same name on the remote and pushes another branch with a different name to remote then submit a PR, while I really just want it to use the existing branch for PR.

[abhinav]

Thanks for the issue, @ArpanSriv.
I'd like to dig into the repo sync getting stuck. Could you clarify more what happened.

You're right that git-spice's local state doesn't get transferred between machines, although when importing open PRs, it tries to relearn some of this information. (Strictly speaking, the state is just in a Git ref so it could be pushed to GitHub. I haven't thought about out how that would work/break yet.)

@messense

pull it on another machine, make some changes, run gs branch track and gs ss it detects that there is already a branch with the same name on the remote and pushes another branch

Try this instead:

• Pull the branch on another machine
• Without making any changes, run gs branch track && gs branch submit --dry-run
• Make changes and submit

Explanation: gs branch submit attempts to match against open PRs with the same branch name if the branch's local state doesn't have a PR attached, but only if the remote branch hash matches the local head hash.
If the hash doesn't match, it picks a different name to guard against the case when you and your coworker both use the same branch name.
So the way to make it match a specific open PR is:

• have the same name and same hash at initial submit so it picks up the state
• explicitly tell it the upstream branch name with git branch --set-upstream-to=origin/feature1 before submission—this will be treated as authoritative

I think a gs branch import command might make sense to do this in a more reasonable way.

Also note to self: possible improvement to matching logic here: if remote hash doesn't match, but it is reachable from current branch head and there are no other branches between current head and remote hash, it's probably still the same branch.