This message was deleted.

Hmm, this one's a bit of head scratcher — was your branch fully restacked on his?

Hmm, what do you mean by “restack”? These were my steps: 1. Check out his branch 2.

gt branch track

3. Write my code 4. Submit my diff

The reason why this happens sometimes is because of how GitHub determines which diff to show — to visualize, imagine something like this (in commit-land):

B
   |
A  A'
|/
M

I'm assuming that your PR has your branch set as the head and your coworkers set as the base (this is what

submit

should have done) If your branch is pointing at commit B and your coworker's is pointing at commit A, GitHub will vend us the diff from M to B because M is the merge base of A and B — "fully restacked" above was referring to having your branch based on the correct version of it's parent

Ah - did I accidentally create

A'

when I did

gt branch track

on his branch?

branch track

shouldn't do that

His branch only has one version, and it’s the commit he made yesterday

if you run

git log --oneline

from your branch locally, does that commit show up in the history?

Yes

I don't see

91ccd2d

there —

Oh hmm, yeah, you’re right

This should fix

git checkout <coworkers branch>
git reset --hard 91ccd2d
git checkout <your branch>
git rebase --onto <coworkers branch> HEAD~
gt branch track
# select coworkers branch from the menu

Ooh yeah - I clicked submit on my branch only because I didn’t want to mess with his branch

i'm still working on exactly what the right solution is here — for graphite-only collaboration we're getting closer and closer to having automatic rebasing be the norm, but non-graphite-graphite collaboration is a little harder of a case