https://linen.dev logo
Join Slack
Powered by
This message was deleted.
# feature-requests
s
This message was deleted.
🤩 1
💯 1
➕ 1
e
An example: imagine you have two stacked PRs, 
feature-a
and 
feature-b
:
Copy code
* 0379b46e8 (HEAD -> feature-b) Work for feature B
* bd1a7fa86 (feature-a) Work for feature A
* 3a7cb2819 (master) Base foo
Right now, you’d make two PRs: • Merging 
feature-a
into 
master
• Merging 
feature-b
into 
feature-a
In this alternative world, we’d make a 
base/xxx
branch for each PR:
Copy code
* 0379b46e8 (HEAD -> feature-b) Work for feature B
* bd1a7fa86 (feature-a, base/feature-b) Work for feature A
* 3a7cb2819 (master, base/feature-a) Base foo
And the two PRs would be: • Merging 
feature-a
into 
base/feature-a
• Merging 
feature-b
into 
base/feature-b
If the first PR for 
feature-a
is landed onto master, the PR for 
feature-b
remains intact and untouched - the UI on github still only shows that the PR has one commit
Copy code
* fdda0084e (HEAD -> master) Work for feature A
| * 0379b46e8 (feature-b) Work for feature B
| * bd1a7fa86 (base/feature-b) Work for feature A
|/
* 3a7cb2819 Base foo
The other benefit is if multiple users are working off of a stack: for ex, a stack of backend PRs (aka 
feature-a
) with a frontend eng working on a stack of frontend PRs (aka 
feature-b
) off the current tip of the backend feature stack. Right now, if 
feature-a
is updated and force pushed, 
feature-b
ends up in this wonky state containing all of the commits from 
feature-a
I worked with phab for a long time, and when I left for another company, I built my own CLI that did this 
base/xxx
thing - until i found graphite 🙂 both flows have their pros and cons, and the 
base/xxx
approach is admittedly really difficult to retrofit to work with Github’s merge-centric world. But I would be beyond intrigued to play around with a mode of the graphite CLI that did manage its own explicit base branches
a
This would be absolutely incredible to have support! Really curious on the graphite team’s feedback here 🙂 ^^
e
Another side effect of the current method using shared base branches is that updating only 
feature-a
on the bottom of a stack falsely causes 
feature-b
to temporarily display that it has changes from earlier version of 
feature-a
. This is fine as long as you restack and push the rest of your stack, but if you use github 
CODEOWNERS
, all code owners of 
feature-a
will be incorrectly added to the review of 
feature-b
and must be removed manually sad parrot Any thoughts on this approach?
a
cc @Jacob Gold who likely has the strongest opinions here
j
Really cool idea! One of our primary goals has always been super-solid interop with non-Graphite GH workflows.
e
It’s still interoperable, with quirks - when you merge in GH UI, you have to adjust your base branch to master. Inconvenient for sure, but so many benefits for a stacked workflow. I almost see this method as an extension for graphite power-users who want the stacks to work seamlessly for them. It doesn’t have to be a hard cutover, I imagine the two modes could coexist with a setting in the graphite cli. Would the team ever configure supporting a second mode like this, or the ability to add custom behavior at stack submit time?
j
Definitely something I'll consider -- our more likely first path will be to do these rebases automatically, to be transparent
e
Ooh fascinating - like if someone updates 
feature-a
, a graphite job with automagically rebase 
feature-b
in the background and push?
That would definitely help a ton for a lot of these use cases. I can see one side effect: we’d automatically re-trigger CI for all of the PRs on top of the stack. I can see how some cos actually want that as desired behavior, but if your CI is relatively expensive, some cos might want to minimize CI retriggers on just code changes to the PR itself rather than rebases
👍 2
j
That's a great point, appreciate the flag
🙏 1
e
👋 Any updates in thoughts or feature development here?
j
We've been thinking about the evolution of the workflow along this dimension, but in very early stages so far. Our current thought is that we can likely provide better UX on stacks for teams that are all using Graphite (like the way in which you mention here) at the cost of making the experience for team members still viewing PRs on GitHub less clear than it currently is. Your suggestion to allow configuration between the two modes is likely how we would do something like this. Again, very early stages — cc @Tomas Reimers or @merrill for viz in case you have anything to add or any research questions. Separately, I see that in the thread I was also discussing the auto-rebase stuff — we've built that and experimented with it internally but have put it on hold due to how it felt to actually use day-to-day. We're looking at read-only solutions to the "needs a rebase" case for the near future (e.g. some sort of notice/explanation).
🚀 1
e
Wow, you made my evening! 🙂 very happy to hear it’s evolving, but I acknowledge it’s a huge change. This today is one of our biggest pain points in working with stacks. More than happy to help in any way that I can - bouncing ideas around, elaborating on our use cases, testing janky first iterations, you name it
❤️ 1
Open in Slack
PreviousNext
Powered by