are there still plans to support multi-trunk workf...
# how-do-i
d
are there still plans to support multi-trunk workflows?
a
We're working on this!
🎉 1
d
this would be amazing
j
Can you briefly remind me what your specific multi-trunk setup looks like and the deficiencies of using Graphite with it today? (cc @Taksh Singh)
d
the main issue arises for us because we don't want continuous deployment for features that are in progress, but we want those in progress features to be able to be broken down into smaller chunks that are reviewable while also being kept up to date with the current release; we develop blockchain smart contracts that are versioned, you can think of them as pieces of hardware that once a version is deployed, it is permanent/forever, so there are consequences with merging into main, from which our contracts are deployed/versioned. so we want to be able to continuously work on a longer feature of a smart contract which is eventually to be released, but have this composed from multiple small diffs which can easily be reviewed and merged, while also being able to rebase/update it from the main branch. cc @Iain Nash if you want to can think of some more context here
👍 3
related, the thread above re:private/public workflows. i believe multi-trunk would offer some approaches to solve this
i
That's exactly our issue: We don't have the luxury of fast/often deploys and sometimes need to chunk work to allow for upstream smaller bug fixes to be merged into main and released in parallel to larger feature work in other branches.
t
@Dan Oved @Iain Nash thanks for your feedback! Do you usually work on multiple feature branches simultaneously? Or do you have a long-lived feature branch where all changes go into?
d
we have multiple feature branches simultaneously
👍 1
a big win for us would be able to just merge once branch down the stack after its approved, kind of like how you can
gt fold
thank you so much for getting this out!!!