This message was deleted.

I also would like this, or something like it. It'd let me break up my PRs a bit more without worrying about what'd happen if one landed without the other. So for features A and B, I could have

A1 > A2 > A3 > B1 > B2

, and be able to squash the `A`s together, and the `B`s together, so that when we have issues, reverting main to any landed commit is always safe.

I know this is an old thread, but I recently joined this slack community hoping to find a solution to just this. I've converted most of my eng team to using Graphite over the past few weeks, but we've been hitting the same issues with jumps in our CI costs as we'd like to require passing tests before merging each PR to trunk. @Matt Demichele Have you found another solution/workaround, or have you been folding each diff in a stack individually into the parent of the stack?

Not really @Matthew Hokinson - for now just using graphite as it works today and accepting the CI costs. I think the other answer is to pay for the graphite merge queue 🙂. For a really big stack, sometimes we will manually

gt fold

everything. I have a dream of one day turning the above steps into a github action to automate it, with an additional extra step of taking everything folded and creating a separate PR so that the title/description make sense, instead of it just being the title/description from the bottom most PR. Haven't found the time for that one yet though

Is this something like this in the roadmap for Graphite? It's looking like a make-or-break feature for our organisation