Tangentially, I like to work with Gerrit [1], which approaches the core problem in a different way...
"Stacked branches" seem to be a terminology which derives from Github/etc's approach to Pull Requests, where one PR maps to one atomic change. The PR can either be integrated in the repo as a merge, in which case you maintain the history of the PR and all its changes through its reviews, or as a squash-merge, in which case you flatten the PR's review history into one commit.
But what if you want to maintain a series of separate but related commits? PRs don't really help you there, so people ended up inventing the concept of Stacked Branches, as discussed in the article.
Gerrit took a different approach, and requires you to add metadata to each commit's message, the Change-Id. This way Gerrit can track your commit through its review evolution (since its SHA will change with each iteration). This also allows Gerrit to trivially track a series of related changes through their overall evolution, since it can use git's normal branch data to track commit's relation to each other, and the Change-Id to track one commit as it evolves.
In any case, both solutions demonstrate that Git lacks a way to track the evolution of specific commits throughout their review history (a 2D branch in a way), so review tools like Github/etc and Gerrit had to create their own solution on top of it.
Yep, Git's semantics are seriously lacking (see also renames). In Reviewable, we work around this with heuristics: we use Change-Id if it happens to be available, and otherwise do best-effort loose lexical matching on the commit messages to match up pairs across a rebase. It works reasonably well in practice but it's a bunch of complex code that I'd rather not have to maintain...
i like gerrit as well. There is a sizable population of developers working on google's projects android/chrome etc. that is well versed with gerrit. I am surprised there is no company that provides gerrit service for people who don't want to move to github. Other git hosting services also try to emulate github with similar workflows. I would love to host projects on gerrit but i don't want to manage it by myself.
> To rebase the part-2 and part-3 branches, we would have to run something like this:
# Rebase commit 4 and commit 5 on top of the part-1 branch
git checkout andrew/feature-xyz/part-2
git rebase HEAD~2 --onto andrew/feature-xyz/part-1
# Rebase commit 6 on top of the (now rebased) part-2 branch
git checkout andrew/feature-xyz/part-3
git rebase HEAD~ --onto andrew/feature-xyz/part-2
What's the supposed benefit of this over simply the following?
git rebase andrew/feature-xyz/part-1 andrew/feature-xyz/part-2
git rebase andrew/feature-xyz/part-2 andrew/feature-xyz/part-3
This won't work correctly because after the first command, part-2 will no longer be an ancestor of part-3. It will try to rebate commits that already exist on the target, leading to unnecessary and difficult merge conflicts.
When I was doing more hardcore dev instead of SRE'ing I settled on git branchless[1], was well worth the experimenting you have to do to get it into your mental model.
now that I hardly ever have 2 layer deep stacks I just settle on my go-to git client which is magit. It just takes a couple of keystrokes to do a couple of stacked rebases.
I do wish that the stacked commits approach was universally used instead of the approach that github enforced on us. It just makes everything a bit less arcane. The whole 'branch-dance' gets really old real fast.
[1]: https://github.com/arxanas/git-branchless
Graphite costs $25/month per user and there's no free tier I can use on enterprise. No matter what productivity gains I might derive from Graphite, I will never be able to convince my boss to pay for it, just because there's no way to prove that said gains exist.
And because there's no individual tier, I couldn't pay for it myself if I wanted to. Honestly, I would if I was forced to switch to GitHub, because stacking on Gerrit has increased my productivity by 2x as I'm no longer blocked on code reviews. Even a tiny pay gain because I'm now a top performer is worth the $25/month to me.
"Stacked branches" seem to be a terminology which derives from Github/etc's approach to Pull Requests, where one PR maps to one atomic change. The PR can either be integrated in the repo as a merge, in which case you maintain the history of the PR and all its changes through its reviews, or as a squash-merge, in which case you flatten the PR's review history into one commit.
But what if you want to maintain a series of separate but related commits? PRs don't really help you there, so people ended up inventing the concept of Stacked Branches, as discussed in the article.
Gerrit took a different approach, and requires you to add metadata to each commit's message, the Change-Id. This way Gerrit can track your commit through its review evolution (since its SHA will change with each iteration). This also allows Gerrit to trivially track a series of related changes through their overall evolution, since it can use git's normal branch data to track commit's relation to each other, and the Change-Id to track one commit as it evolves.
In any case, both solutions demonstrate that Git lacks a way to track the evolution of specific commits throughout their review history (a 2D branch in a way), so review tools like Github/etc and Gerrit had to create their own solution on top of it.
[1] https://www.gerritcodereview.com/