Skip to content

Conversation

@mtsgrd
Copy link
Contributor

@mtsgrd mtsgrd commented Jan 19, 2026

It seems we determine the LocalAndRemote status on the commit being reachable by any remote, rather than matching on the specific remote and branch.

I noticed the problem when I had two stacked branches, where the remote bottom branch included the commits of the local only top branch. They were both colored as pushed and matching upstream, and the push button was disabled as a consequence.

*edit: code is 100% generated by Claude, so most likely incorrect.

Pass the remote tracking branch ID into local commit collection and use it to detect which local commits are also present on the remote tracking branch. This fixes incorrect commit state reporting by building a revwalk of the remote tracking branch, comparing commit ids, and setting commits to LocalAndRemote or LocalOnly accordingly. Also update callers and a flag name to match the new remote reachability meaning.
@vercel
Copy link

vercel bot commented Jan 19, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Review Updated (UTC)
gitbutler-web Ignored Ignored Jan 19, 2026 2:29pm

Request Review

@github-actions github-actions bot added the rust Pull requests that update Rust code label Jan 19, 2026
@mtsgrd
Copy link
Contributor Author

mtsgrd commented Jan 19, 2026

@Byron this PR was entirely generated by Claude so maybe disregard the specifics. I was debugging why the top branch had commits that appeared LocalAndRemote when in fact those same commits only existed on the remote in the bottom branch.

Claude seemed to confirm that we only check that the commit is reachable on any remote, while it feels to me the check should be for the specific remote, and reachable from a specific branch. Does this make sense to you?

image image

@mtsgrd mtsgrd changed the title Include remote tracking branch when listing local commits Determine LocalAndRemote commit status based on matching remote _and_ matching branch name Jan 19, 2026
@Byron Byron self-assigned this Jan 19, 2026
@Byron
Copy link
Collaborator

Byron commented Jan 19, 2026

Thanks a lot for digging into this! I also think this should be fixed, and can be fixed. Will get to it right after #11887 .

@Byron
Copy link
Collaborator

Byron commented Jan 23, 2026

As getting into this could be a huge time-sink, I had to put it onto my backlog to be able to focus on unapply(). The only consolation I can give is that I let it jump the queue and put it second.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rust Pull requests that update Rust code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants