https://linen.dev logo
Join Slack
Powered by
This message was deleted.
# feature-requests
s
This message was deleted.
👍 1
t
Oh wow, how’s it going Nader, long time no see. Small world!
n
To clarify, imagine you have the following stack: • main • feature/big-feature-branch ◦ This is like a staging branch for a really big feature. In our case it's a major upgrade to our blockchain's consensus that requires a bunch of improvements (proof of work -> proof of stake). • feature/small-feature-branch ◦ This is what people work off of What we want when we do a restack is: • Pull the latest updates to main • Merge main into feature/big-feature-branch using a merge commit at the tip of it • Merge the resulting feature/big-feature-branch into feature/small-feature-branch, again using the merge strategy Instead what Graphite does is: • Pull the latest updates to main • Try to rebase feature/big-feature-branch onto the new main ◦ This fails because this branch has over 200 commits. A merge, in contrast, is super easy barely an inconvenience. And that's where we get stuck 🙂
👍 1
Oh WOW man long time indeed @Tyler Laprade! Hope you've been amazing man!
❤️ 1
j
This is not something we support or have plans to, I’m afraid — the way we keep track of branch dependencies is not compatible with merge commits
I imagine there is some scripting you could do to get the merge commit part how you want it, but i don’t see how graphite would be useful for this flow… maybe i’m missing something
n
@Jacob Gold no problem. Out of curiosity, could you elaborate on how you track branches and what makes it not conducive to a merge-based workflow? From working with graphite, it seems like it tracks the metadata about branch dependencies separately from the commit data, which would then make it just a flag-flip to use a different stacking strategy. The reason I brought it up is actually because I'm currently merging my branches manually rather than restacking. In particular, I just do a manual git merge up my stack almost exactly like a --restack would do (only that command uses a rebase strategy), and it mainatains the dependency graph of branches perfectly. I'll also add that I do think a lot of people use merge-based workflows! At Google, that is actually the main way things are done, as each CL doesn't have commits within it (though it does track the history of each change like a commit would).
👍 1
j
Graphite only looks at a single parent of each commit — merge commits by definition create commits with multiple parents. We define a "Graphite branch" as not just a pointer to commit, but a pointer to a head commit and base commit, where the single deterministic result of 
git merge-base <base> <head>
is the base commit — i.e. the base is in the linear history of the head. Merge commits make it harder to reason about maintaining this invariant because it introduces the possibility of multiple merge bases. I was at Facebook before this (we have folks from Google on our team as well) and it's my understanding that `hg`/Phabricator at facebook behaves not too differently from Piper — both consider stacks of commits as opposed to branches, and keep track of the version history of the diff/CL respectively. You are correct that this is isomorphic to using merge commits to keep track of the history of a feature, however, we model this differently on top of Git. The main motivation for this difference being that we want Graphite to be fully compatible with Git and GitHub pull requests so as to allow for incremental adoption from fully GitHub to fully Graphite. We keep track of the version history of the Graphite branch on our server, outside of Git itself. (i.e. a history of the head/base commits updated on each 
submit
command or when we detect that the branch was updated via a non-Graphite push)
Thinking more about your specific case, what you might want here is to set your trunk branch locally to your 
big-feature-branch
and base your stacks on that instead of main. Our CLI will then rebase 
small-feature-branch
to restack it on 
big-feature-branch
without trying to restack 
big-feature-branch
on 
main
. You can change your trunk branch with 
gt repo init
. In this world, you would manage merging 
main
into 
big-feature-branch
and pushing 
big-feature-branch
to GitHub outside of Graphite. Perhaps a better statement of what I said earlier is that Graphite is designed and best used for managing stacks of small, short lived branches that merge into longer lived "trunk" branches. If you are willing to treat 
big-feature-branch
as a trunk branch, and manage its relationship with 
main
outside of Graphite you may see more value from it.
👍 1
6 Views
Open in Slack
PreviousNext
Powered by