4 ms·

Working with stacked branches in Git is easier with –update-refs (2022)

65 points by canpolat 2y ago

deleted 2y ago
[deleted]
nosefrog 2y ago
Whoa, didn’t realize I need this. I’m constantly rebasing stacked branches.
tcoff91 2y ago
Graphite makes this workflow a lot easier.
- jjmarr 2y ago
  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.
  - positr0n 2y ago
    If you are stuck on GitHub, tools like revup can help you get the same workflow.
randoglando 2y ago
Does this work with `git pull --rebase`?
- 3np 2y ago
  Yes. It also works with `git status`, `git log`, and `git push --force-with-lease`. (It's not clear what you're asking about)
  - randoglando 2y ago
    I would expect this to update all branches when I do `git pull --rebase` but looks like it doesn't do that?
deleted 2y ago
[deleted]
eternalplatypus 2y ago
This is awesome thank you for sharing. I had almost given up on my git workflow because of how tedious the process of rebasing was getting.
3np 2y ago
> 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
- exclipy 2y ago
  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.
AceJohnny2 2y ago
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. [1] https://www.gerritcodereview.com/ https://www.gerritcodereview.com/
- piotrkaminski 2y ago
  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...
- newusertoday 2y ago
  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.
hbogert 2y ago
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 https://github.com/arxanas/git-branchless

65 points by canpolat 2y ago

deleted 2y ago

[deleted]

nosefrog 2y ago

Whoa, didn’t realize I need this. I’m constantly rebasing stacked branches.

tcoff91 2y ago

Graphite makes this workflow a lot easier.

jjmarr 2y ago
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.
- positr0n 2y ago
  If you are stuck on GitHub, tools like revup can help you get the same workflow.

randoglando 2y ago

Does this work with `git pull --rebase`?

3np 2y ago
Yes. It also works with `git status`, `git log`, and `git push --force-with-lease`. (It's not clear what you're asking about)
- randoglando 2y ago
  I would expect this to update all branches when I do `git pull --rebase` but looks like it doesn't do that?

deleted 2y ago

[deleted]

eternalplatypus 2y ago

This is awesome thank you for sharing. I had almost given up on my git workflow because of how tedious the process of rebasing was getting.

3np 2y ago

> 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

exclipy 2y ago
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.

AceJohnny2 2y ago

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. [1] https://www.gerritcodereview.com/ https://www.gerritcodereview.com/

piotrkaminski 2y ago
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...
newusertoday 2y ago
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.

hbogert 2y ago

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 https://github.com/arxanas/git-branchless