This message was deleted.

The reason I'm asking this is that I tried to take an existing chain-of-pull-requests in an existing repo and track it in Graphite, but failed to squash the pull requests and got absurd merge conflicts, without knowing what I did wrong. But I failed to reproduce the same issue in a toy example 😞

If other things merged into

main

aside from

a

and

b

, those could conflict. But I'm guessing in your situation, that's not part of this?

Hm, I am not completely sure

I think

b

will conflict with itself, because hashes changed.

Ha that might be the answer I am looking for! Thanks, looking

Yeah same, don't think it does that quite yet

Which means that if you have GitHub branch protection set to squash merges, I sometimes have to manually do this

git rebase --onto

? Or does it work differently when using GitHub's squash vs

gt branch squash

?

I don't know about squash and merge. Actually I've personally been using rebase and merge, as long as we "just rebase and merge", the downstream branches restack fine without conflicts... But I have had issues under these circumstances: • Coworking restacks and submits • I have a local commit on top of latest branch • I would wish it would pull whatever coworker submitted (force pushed) and

git rebase --onto

my last local commit, but it doesn't do that • It only gives me the option to "rebase entire stack onto remote stack", which runs into self-conflicts, or to overwrite local with remote, which makes me loose my local commit • So I'm forced to manually

git rebase --onto origin/latest_branch <hash-of-local-commit>

Hey there! We're making some improvements to collaboration in the CLI and will certainly bring this situation up with the team :)) thanks for the contributions guys!