A key benefit of using Graphite as opposed to vanilla Git when working with stacks is dependency management for your branches, i.e. keeping track of the "parent" of a given branch. When a parent branch changes in some way or is deleted, vanilla Git, because it does not have this concept of branch dependencies, leaves the parent as is.
The Graphite CLI introduces "restacking", which is the process of ensuring that the history of a branch is updated when its parent changes. Consider where we left off on the previous page after running
gt repo sync. Although
part_2is now dependent on main, we haven't yet restacked it, and we can see that by viewing the Git history with
gt log long:
We see that
mainhas advanced to the squash-and-merge commit for
part_2, even though it is supposed to be based on
mainnow, is actually still sitting on the old version of
part_1. We can fix that with
gt upstack restack. This command, for the current branch and all recursive descendants, ensures that they are based on the current version of their parents.
The results of restacking
After running our
restackcommand, we can see that Git and Graphite are in agreement about the history. Now, we might want to resubmit the restacked versions of these branches (
gt stack submit), or maybe make some changes to them first to address review comments (see the following page).
Restacking is running a
git rebaseunder the hood, and as with any rebase, you may run into conflicts, in this case between the branch you are restacking and the new version of the parent. Just like with git, you will be prompted to resolve conflicts before continuing, which you can do with
gt continue, which is described in a little more detail in the next section.
submit, there are
branchrestack commands. It is likely that most of the time,
upstack restackwill be the main commands that you use —
branch restackare included for completeness.