This message was deleted.
# feature-requests
s
This message was deleted.
p
Hey there! If you merge a stack from the Graphite UI, it takes care of all the rebasing/merging of the dependent PRs - is this the use case you're looking to address?
a
No, I’ve discussed this several times with y’all. If I have an on-merge workflow for merges into main that say, take an hour each run and cost resources. Why would I want to wait for each workflow to complete for each patch in a 5+ patch stack? It could take an entire workday to get the last patch in which would slow down the velocity of my team. Our preferred workflow is one feature is comprised of many small patches so this is a waste of time and money. Merging from leaf down to trunk only runs the on-pull workflows because those are merges into non-main branches which are significantly shortly and less expensive. Even better, The on-pull workflows already run against the leaf so you know you can merge them down to the branch just before main and get the same results. My company does that manually for most of our repos at this time, manually fold patch/branches together and then do a final merge into main. This would be a significant improvement for customers that are deploying production resources from GitHub workflows.
Does my existing workflow make sense? I’m happy to explain more
x
Hey @Andre Gagne (Qumulo) thanks for the feature request! Let me try to reiterate the ask so that I’m clear (please correct me if I’m wrong here): • You wish to not merge PRs from stacks directly to trunk because you have a lot of tests that run when you merge into main • Graphite could help by: ◦ Making it easier to merge stacks into branches that aren’t trunk (eg. leaf branches) ◦ and adding a feature to then automatically merge that leaf branch into trunk once the stack merges into the leaf branch Question: • Does your team use a merge queue and if not, are they interested in using a merge queue?
a
We had a call with y’all about Merge Queues when it came out. From your own description, it didn’t solve the problem because it still treated each merge into the truck as a separate merge. I believe we talked to @Jacob Gold and @Carissa Jansen about this. I’m happy to give the example again.
x
Got it, yeah sounds like then you want something like batching which we’re still working on for the merge queue. We can let you know when we have this released, but thank you for the feature request. This helps us to prioritize what we work on!