Hey yall. I guess this could go in your <#C06C4TH0...
# how-do-i
a
Hey yall. I guess this could go in your #C06C4TH0D27 channel instead cause I'm reasonably confident you guys just don't support this (and I think you should), but is there not a way of doing either a
gt sync
or
gt restack
with a merge strategy rather than rebasing? and if there's not could I get like... an explanation of why we don't have the option of a merge strategy if its a purposeful decision? I work for https://jump.ai/, and we have quite a few engineers at the company using Graphite, and I think a lot of us would really like this feature.
✅ 1
p
(If applicable) To help us more clearly understand what you're trying to do, please provide additional details about: - Screenshots / debug logs / list of commands you've tried to run so far - Your workflow - Current state
hey andrew. you're right. unfortunately we don't support this today.
gt sync/gt restack
is the local-restack side and doesn't currently have a merge-strategy alternative. from my understanding, the reason why is because stacked PRs in Graphite are modeled as a linear chain where each branch has exactly one parent at one specific commit.
gt sync/gt restack
reconcile that chain by replaying commits onto the new parent, which makes the difs stay clean and allows us to automatically detect/clean up once the parent branch merges.
a
I don't really understand how anything would change if there were merges instead
For instance you can merge-reconcile upstream changes yourself
Just manually merge main into the bottom of the stack, then the bottom into bottom-1, etc
It does not seem to irrevocably break graphite when you do this
I could write a script to automate this process and just go on my way, but I just don't understand why you guys can't just offer it as an option
When you run restack, it just goes to each branch one by one and rebases against the branch under it, yeah?
What would change if that were a merge instead?