15 ms·

In Praise of Stacked PRs

225 points by kiyanwang 4y ago

knoebber 4y ago
I like to do this to address PR feedback, mostly because we use bitbucket, and it's UI for reviewing individual commits sucks.
sandspit 4y ago
Another one: git-town https://www.git-town.com/ https://www.git-town.com/
moffkalast 4y ago
Well this would be impossible to explain and coordinate with the team
- catskul2 4y ago
  Clearly not the case. A very large number of people use these sorts of flows without problems coordinating or explaining.
rsstack 4y ago
We switched to using https://graphite.dev/ https://graphite.dev/ after yet-another huge epic that caused a mess of PRs and one PR that touched 100+ files and included dozens of semi-related changed. It's been a blessing so far.
- zeroonetwothree 4y ago
  Graphite is amazing! Would definitely recommend everyone try it at least :)
- shepherdjerred 4y ago
  How is Graphite? Does it solve the problem of stacked diffs well? I loved the CR tool at Amazon where I could create CRs for arbitrary commit ranges, and I really want to find a similar tool.
- thurn 4y ago
  Little suspicious of a tool with no pricing information from a company that just raised $20 million. I assume it will not remain free.
rco8786 4y ago
Hope you like merge conflicts and rebase hell as people start to comment and ask for changes
nateroling 4y ago
I’ve played with this idea a bit. In my experience it felt like a hack to work around the fact that individual PRs took a while to get merged. An alternative solve is to work in a way that allows PRs to be merged more quickly, ie pairing, mobbing, or prioritizing getting reviews done asap.
- tennis_80 4y ago
  Yeah I agree. If you can merge things into a central branch quickly, it’s much better. In my experience with this sort of process you spend quite a lot of time managing your different branches, especially once you start getting feedback and requests for changes. Then keeping everything in sync. Git helps make this quicker but it’s still effort & cognitive load.
- avl999 4y ago
  It is more about being unblocked than however long it takes for the PR to be merged in even if it is really fast. It is not always possible to pair/mod on a change. Getting folks to quickly review PRs is difficult as doing so breaks the flow state of other people and results in constant thrashing and context switching between the work they are doing are reviewing PRs. Even if the team is committed to quickly reviewing PRs, you are always going to have times when a bunch of people are in a meeting, while a couple are at lunch and a couple are knee deep in another issue and no one can look at your PRs for hours and you need to keep yourself unblocked.
doktorhladnjak 4y ago
We use GitHub Enterprise where I work now. I do sometimes do stacked PRs but GHE does not make it easy. The rebasing and merge conflict resolution can be a headache although git rebase —onto helps a lot. I previously worked somewhere that used Phabricator. Its “stacked diffs” worked great. I’d use it all the time when working on complex, multipart changes.
- arxanas 4y ago
  Try out the linked tool git-branchless (https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless, I'm the author). It should help you restore Phabricator-like workflows. In particular, check out the `git sync`, `git restack`, and `git move` commands for handling rebasing and conflict resolution.
  - doktorhladnjak 4y ago
    Unfortunately I cannot install the rust compiler tool chain or other third party binaries on my work laptop :(
    - tcoff91 4y ago
      You don’t have the ability to install tools on your work computer? That would be a deal breaker for me.
dcow 4y ago
I’m going to be a little crass for a moment: people don’t know how to use their tools! Why are we even talking about “stacked PRs” and “branchless” workflows?! It’s clear the author is documenting their git learning process and that’s great, really. But I’m just surprised how pedantic people get about forcing others to use a tool in a way that caters to their own limited understanding of it. Or, even worse, caters to limitations in the 3rd party UI being used to interface with it (ye ol’ git vs GitHub problem). Learn your tool and then you can worry about the higher order things that are supported by it.
- seoaeu 4y ago
  This comment would be more compelling if it gave any hint about what aspect of the tooling the author didn’t understand or what they should be doing differently.
  - dcow 4y ago
    I’m not talking about the author, specifically or criticizing them directly. I’m lamenting how often I encounter people putting intense amounts of effort into arguing about how git should be used. My hypothesis is that if people understood their tools better before getting all evangelical about forcing their entire eng team to work in their style, others wouldn't have to spend so much time trying to convince them that other styles are exist and are valid. Compare with a construction site: there are obvious uses for tools and there are less obvious uses and I haven't been on a single one where tools are only used specifically in one way for the entirety of the project. They’re used dynamically by different people with different experiences in order to complete the project. Nobody forces other workers to use a specific grip when holding their hammer…
    - johnfn 4y ago
      I'm not understanding how stacking PRs is inconsistent with knowing git well.
      - morelisp 4y ago
is0tope 4y ago
I've usually kept a rule that you should avoid stacking, and if you must only one level deep. The fact that you have to stack in the first place typically suggests that PRs aren't being merged fast enough. Stacking in my personal experience usually leads to merge conflict hell as changes and PR suggestions get merged underneath you.
- BerislavLopac 4y ago
  My personal rule of thumb is to rebase the working branch as soon as the main has been updated; or at least merge main if the changes are too complex.
- ramraj07 4y ago
  It’s unavoidable sometimes. I get inspiration and time together rarely, I can’t wait for small chunks of code to be merged before I continue. A lot of times it’s an extremely Productive Sunday afternoon and I have 2500 new lines of code that builds a full new prototype. What am I to do?
  - pizza234 4y ago
    I understand that (experienced the same "problem" today), but writing "2500 new lines of code" on a Sunday afternoon is (hopefully) not representative of regular workplace conditions.
    - zeroonetwothree 4y ago
      Some people enjoy their work. I think it’s fine as long as it’s a choice.
      - NateEag 4y ago
        It may be fine. Keep in mind, though, that humans are not perfect and some choices are unwise.
    - ramraj07 4y ago
compsciphd 4y ago
One thing I wish git did (maybe it does and I don't know how?) is to be able to say that a new branch is based off an old branch (not a commit that used to be that branches head). so I can branch a single pr in progress to start the next. Then if I change the base pr in progress (say via rebase or via squashing or the like), I can easily rebase my new commits in the new pr on top of the current state of the branch. Currently, one can just do it by never modifying the underlying "branch" (i.e. just adding new commits), but in practice that doesn't always work, as many times you have to rebase against one's master/main branch to pull in changes, which even if no conflicts, will reflow your "base" branch" changing all the commits. TLDR: Basically, want to be able to state that branch depends on branch (which is currently commit id x) but if I rebase, use whatever the current commit id is for that branch, not whatever it was when I first made the branch. possible? stupid idea? thoughts?
- bqmjjx0kac 4y ago
  It sounds like you're describing what `git branch --set-upstream-to=$otherBranch` does?
- regularjack 4y ago
  Isn't that how rebase already works? It will "apply" commits of the current branch onto commits of the base branch, including new commits that were created in the meantime.
- theptip 4y ago
  This is one of the big features from git-branchless (https://github.com/arxanas/git-branchless/wiki/Command:-git-move https://github.com/arxanas/git-branchless/wiki/Command:-git-...) which is recommended in the article; moving a stack (sub-tree) of commits instead of just one branch. Might be useful for you if you find the rebase flow to be painful. In particular this can be good for local prototyping where you have a bunch of functional candidates on top of some foundational refactors, and you may be rebasing frequently to refine those foundational commits.
  - arxanas 4y ago
__derek__ 4y ago
I'm guilty of doing this in the past, but it seems like an anti-pattern because it attempts to create a local optimum, a big no-no in the Theory of Constraints[1]. Better to find ways to sustainably ease the constraint (code reviewers' time/attention) than to find ways to create more WIP at the constraint. [1]: https://en.wikipedia.org/wiki/Theory_of_constraints https://en.wikipedia.org/wiki/Theory_of_constraints
- morelisp 4y ago
  As someone coming down from a nearly 2 year fight with an engineering manager whose response to every bug was enforcing more code review rules, and every code review backlog was demanding more time allocated for code review, thank you for this comment.
- d0mine 4y ago
  Could you suggest some specific alternatives?
- baq 4y ago
  i got a major cognitive dissonance from your comment because stacking PRs is for me the way to get more time and attention from potential reviewers by making their units of work smaller; hopefully small enough to be easily mergable. this is a case of 'more is less' (within reason).
  - __derek__ 4y ago
    I'm confused by your "major cognitive dissonance" comment. What you describe appears to reduce variable costs (time spent reviewing) while increasing fixed costs (context-switching). That may increase code reviewer usage, but that doesn't necessarily increase system throughput or reduce WIP.
    - baq 4y ago
      IME it crucially reduces the time a request spends idle waiting for a reviewer, thus increases total throughput.
ramraj07 4y ago
Any UI suggestions to make stacked PRs easier? Other than graphite.dev - that needs org access on GitHub.
- stitched2gethr 4y ago
  I believe this goes a bit further and decouples the submission from the review. My team reviews PRs very fast, but why should I wait 15 minutes between submitting and continuing my work. Or what about when I'm working late when no one else is online.
surfmike 4y ago
Graphite (https://graphite.dev/ https://graphite.dev/) has been a good tool at our startup to manage stacked PRs, I recommend checking them out.
fallingknife 4y ago
This just shows that people will go to any length to procrastinate PR reviews. The truth is that to be an effective team, reviews need to be highest priority because they are blockers. There is just no way around it.
- macintux 4y ago
  Any categorical assertion like that feels wrong. Not all projects, all teams, all problems are the same.
  - gocartStatue 4y ago
    Lower work in progress generally results in faster & more predictable delivery. PR's are an inventory of "almost finished goods". "Stacking" PR's essentially means delaying integration and increasing WIP.
ridiculous_fish 4y ago
Plugging my own tool: if you like to cultivate a stack of commits, you'll know how awkward git makes it to edit previous commits. With git-prev-next you can run 'git prev 3' and then 'git commit --amend'. https://github.com/ridiculousfish/git-prev-next https://github.com/ridiculousfish/git-prev-next
- maxekman 4y ago
  `git rebase -i origin/main` (or HEAD~N or any other base) with the e/edit action on selected commit will do the same with only built in functionality.
  - ridiculous_fish 4y ago
    Yep, and git-prev-next is built on interactive rebase. It's just a lot faster to run `git prev`, compared to `git rebase -i HEAD^^` and then muck around in a text editor.
- arxanas 4y ago
  The mentioned tool `git-branchless` (I am the author) also supports `git prev 3` followed by `git commit --amend`. See https://github.com/arxanas/git-branchless/wiki/Command:-git-next,-git-prev https://github.com/arxanas/git-branchless/wiki/Command:-git-...
yosito 4y ago
This article uses the term DAG everywhere, but I couldn't find a definition of it.
- scruple 4y ago
  Directed Acyclic Graph. [0]: https://en.wikipedia.org/wiki/Directed_acyclic_graph https://en.wikipedia.org/wiki/Directed_acyclic_graph
avl999 4y ago
I do stacked PRs at work, they work great until someone suggests an invasive change in a PR lower down in the stack. Does anyone have ideas on how to deal with merge conflicts in this type of flow? For example let's say I have the following stack of PRs PR1 -> PR2 -> PR3 -> PR4 The reviewer reviews and suggests a change in PR1, this change causes a merge conflict in PR2 and therefore in PR3 and PR4 as well. And then you have to go in manually resolve the exact same merge conflict all the way through you PR stack in each of the PRs. This gets annoying and hard to work with. Does anyone have a better way of dealing with this pattern of merge conflict? I've tried using git rerere which in theory sounds helpful but doesn't seem to do anything when I strike this issue.
- fire 4y ago
  huh, shouldn't solving the conflict to pr2 create a merge commit that then also solves the conflict in 3 and 4?
  - travisb 4y ago
    It sounds like the OP might be using a rebase workflow. Such a workflow creates many repetitive conflicts because there is no merge commit to record the resolution point. Using a rebase workflow with stacked/cascaded PRs is an anti-pattern that trips up people used to other git workflows where the history depth is effectively only one level deep instead of arbitrarily deep as in stacked/cascaded PRs.
    - xerxes901 4y ago
      I think this is something git rerere is supposed to help with
    - anderskaseorg 4y ago
      You can tell git what the resolution point is using `git rebase --onto`. This can help avoid situations where Git gives extra conflicts form trying to reapply an old version of your change on top of a new version of the same change. You can also use `git rebase --skip` if you recognize that you’ve ended up in this situation.
krooj 4y ago
I've tried this method of taking a large change and breaking it up into smaller, more easily digestible PRs, and it didn't work. Unless you're working with folks that are directly invested in the change, you'll very quickly discover that people have memories worse than goldfish. So, it's a lose-lose situation: can't really do stacked PRs and large PRs will let bugs and other defects through.
- avl999 4y ago
  There is a tradeoff... smaller, digestible PRs result in thorougher and faster reviews but it gives up the "1000 feet view" of the larger feature as far as the reviewer is concerned. Large PRs preserve the larger "1000 feet view" of what you are working on but are likely to be slower to get responses on and most likely less thorough thus a larger chance of things being missed. Almost everyone I've worked with prefers smaller review so I just accept that trade-off of 1
- culi 4y ago
  Can't this easily be resolved by just using feature branches? Make your small PRs into the feature branch but then you still have the ability to compare the branch to main as a whole and get that wider context
jasonhansel 4y ago
Why not just break up your change into small components, then merge each one into master separately, hiding the change behind a feature flag until the whole thing is done?
- travisb 4y ago
  Your suggestion comes after the changes are merged. That is, you wouldn't normally merge anything to master without having it reviewed. Stacked PRs is _how_ you can break up your changes into small components to merge more quickly and block development less. With stacked PRs the changes are broken into smaller pieces because a later PR can depend on an earlier PR. This means it can be developed while earlier PRs are still under review. It also means each review is smaller and therefore likely to complete more quickly. Stacked PRs can also work like patch series in the Linux Kernel development where a large change is broken into smaller independent changes done in the logical order, even if their order of discovery was probably reverse. For example, if you discover you need a refactor or bug fix while halfway through developing a feature. In that case you simply insert a PR earlier in the stack/graph which contains just that isolated fix. In your feature flag example, a common patten would be to have a dozen or so stacked PRs. The early ones do necessary refactors and bug fixes. The middle few add the feature flag and code. The last make the feature flag the default and delete the now obsolete !feature path. Then the prereqequites (which you didn't discover until half-way through) can be reviewed and merged quickly. The meat of the feature is broken up into easily digestible pieces for quick review, but reviewers can get a sense of the entire feature by considering the PR series as a whole; this is especially useful where one PR adds some infrastructure that a later PR uses but both PRs together would be too large to effectively review. As PRs are ready to merge, they can. Often the last couple of PRs which make the feature the default and delete the obsolete code do not merge for quite some time, but they were written when everything was still fresh in the developers head.
jackblemming 4y ago
There's so many articles on trivial things like this and using pretty syntax and less articles on things that actual matter: architecture and design. It's a bit disheartening to hear software engineers argue of if you should put periods in commit titles or if so and so syntax is more readable.
- catskul2 4y ago
  Not at all trivial. If it seems that way to you, then it's likely that you simply haven't worked on a project with the scale and workflows which require this.
  - jackblemming 4y ago
    Have you considered large successful software projects have been done without any of these modern tools or languages? Or are your projects more complicated than the moon landing?
    - catskul2 4y ago
      You seem to be arguing any tools and languages made after the moon landing are trivial unless the project is "more complicated than the moon landing". Is that the argument intended to make?
TazeTSchnitzel 4y ago
Stacked reviews is a very natural pattern if you're using a system like Gerrit, where the unit of review is not a whole branch, but individual commits. Since they are commits, the reviews can have any kind of relationship that commits can have. I think it's a great system, including for some other reasons (it encourages amending and rebasing commits during the review process, which results in a very clean git history). After using Gerrit professionally for several years I wonder how I ever lived with GitHub-style pull requests.
- baq 4y ago
  github pull request review process, UI and the whole experience is very much the worst thing about github for me. there's literally one feature that I like (C-g, suggest a one-click committable change in a comment) and everything else is better in gerrit.
- dimal 4y ago
  How is reviewing individual commits a good thing? Maybe I’m misunderstanding something, but my branches have tons of micro commits that ultimately lead to a larger change. Reviewing each individual commit in that type of branch seems like it would be very tedious, and not useful. The reviewer would be forced to follow my entire process, with all the dead ends and refactors along the way. Seems like it would take a lot longer. Or is there another workflow that I’m not seeing?
  - dodobirdlord 4y ago
    Squash your commits once you've finished prior to sending them for review? Code review of individual commits generally stems from a workflow that expects that each individual commit will contain a change that is complete in and of itself, along with the corresponding tests for that change, so that the project builds and all tests pass at every commit. This makes exploring the change history easier and reverting changes cleaner, and simplifies bisecting the commit history.
  - Groxx 4y ago
    With this sort of system you generally squash your commits together to form one-per-reviewable-thing. Or at least you rewrite things a bit to make it approachable. E.g. I split things apart so one commit is an obviously-correct refactor and the later ones are pure changes. I understand some of the "no, merges are superior because they retain all history" proponents (not claiming you are one, just aiming to head off that flood), but all those dead ends and refactors along the way are just those - dead ends and refactors. They ruin the ability to bisect, for instance, because they are rarely all functional. Intentional commits, like a stacked workflow supports in a tool like Gerrit, lets you have a wonderfully understandable history that works at every point.
arxanas 4y ago
I am the author of the linked tool git-branchless. Happy to answer any questions about stacked PR workflows here or on GitHub discussions https://github.com/arxanas/git-branchless/discussions https://github.com/arxanas/git-branchless/discussions or Discord https://discord.gg/caYQBJ82A4 https://discord.gg/caYQBJ82A4.
tomasreimers 4y ago
I am one of the authors of the tool Graphite (https://graphite.dev https://graphite.dev). We built Graphite because we missed the stack diff workflow we knew from previous job experiences at larger companies, happy to answer any questions (and if you would rather not ask in public, feel free to email me at tomas at graphite.dev).
- shepherdjerred 4y ago
  How much team buy-in does this require? Would everyone on my team need to use Graphite, or could they continue to use GitHubs code review if they prefer?
  - presentation 4y ago
    I tried it, requires no buy in, pretty much everything still properly shows up in GitHub.
    - shepherdjerred 4y ago
      Okay, I watched this video[0] and I'm sold! I'm going to try it out myself, and it seems like my co-workers wouldn't even have to know that I'm using it. Of course, if it works well I'll definitely advocate for it! [0]: https://www.youtube.com/watch?v=cE59cfwWL7M https://www.youtube.com/watch?v=cE59cfwWL7M
davvid 4y ago
There is active work related to teaching "git rebase" to natively support stacked branches in the Git core currently being worked on by Derrick Stolee [1]. If you "stack" your changes across multiple inter-dependent branches it looks like "git rebase" is going to learn how to update related branches using a new "update-ref" command (alongside "squash", "fixup", "exec", etc) that gets activated automatically through a "git rebase --update-refs" command-line flag and config option. (This is from Derrick, not me) """ This is a feature I've wanted for quite a while. When working on the sparse index topic, I created a long RFC that actually broke into three topics for full review upstream. These topics were sequential, so any feedback on an earlier one required updates to the later ones. I would work on the full feature and use interactive rebase to update the full list of commits. However, I would need to update the branches pointing to those sub-topics. This series adds a new --update-refs option to 'git rebase' (along with a rebase.updateRefs config option) that adds 'git update-ref' commands into the TODO list. This is powered by the commit decoration machinery. """ This is under active development (I don't believe the topic has been merged yet) so it's still open for feedback and refinement on the git development mailing list. Thanks Derrick! [1] https://public-inbox.org/git/pull.1247.git.1654263472.gitgitgadget@gmail.com/ https://public-inbox.org/git/pull.1247.git.1654263472.gitgit...
- hinkley 4y ago
  Is that likely to help with permanent forks or will that still continue to be an issue?
- timhh 4y ago
  That sounds great! I have partly solved this issue in my autorebase tool (https://github.com/Timmmm/autorebase https://github.com/Timmmm/autorebase) - it basically rebases every branch, and fixes the commit time so that stacked branches get preserved even after a rebase just because the hashes all match properly. That obviously doesn't work if you modify or drop any of the commits, so this option is very welcome!
- shepherdjerred 4y ago
  This would be such a great addition! It doesn’t get stacked diffs to quite native support within Git, but it’d be a very good step in that direction
loloquwowndueo 4y ago
Bzr has a pipelines plug-in which does basically this. Branches can be stacked on top of each other forming a “pipeline”, and propagating changes from one branch to the dependent / subsequent ones is achieved with one command, “bzr pump”. Bzr has no concept of rebasing, so what you get is a simple merge, but with very little work on your part.
somehnacct3757 4y ago
I like to figure out what all my PRs will be during the planning phase, optimizing for reviewer cognitive load and incremental development of shippable features. I never need to stack PRs cuz I can work on the next one while the first one is under review and rebase once it's merged. I can see if the review phase is long at your company that this wouldn't work. But I prefer it if possible. One thing I hate about stacked PR delivery is ppl go dark for a month building this whole new world and if you have architecture concerns in the root PR they will resist them because it means rebasing and changing all the downstream PRs as well. Bad incentives all around.
- arxanas 4y ago
  You might be interested in https://github.com/gitext-rs/git-stack https://github.com/gitext-rs/git-stack, which perfectly implements your workflow where you only put up one PR but continue to work locally on the next commits. > ppl go dark for a month building this whole new world I think this isn't specific to stacking PRs. You can put 100 commits in a PR and submit it at once, or you can make 100 PRs and submit them all at once, and have the same problems either way. Ideally, you put up your first few commits or PRs early so that they can get reviewed.
tunesmith 4y ago
How would you align this with Jira stories? Our team tries to maintain a one-PR-per-story flow. Partly for QA purposes, we don't want multiple QA cycles per story. Of course, we still have giant PRs that touch 50-100 files and take forever to code review. And yet, for those stories in question, they do make it to prod faster than if they were broken apart into multiple 1-2 point stories. I imagine as always the answer is "invest in better tooling". More robust automated tests, push-button millisecond-deployments, etc...
- arxanas 4y ago
  Basically: you don't :) I've only ever found this workflow to work if you can attach multiple commits/code reviews to single higher-level work items in your project management software. There's simply too much overhead if you try to correlate project management items one-to-one with commits/code reviews.
bvrmn 4y ago
Mentioned tools seem highly underfeatured comparing with stacked git[1]. [1] https://stacked-git.github.io/ https://stacked-git.github.io/
- arxanas 4y ago
  Hi bvrmn, I've been meaning to write a comparison of git-branchless with Stacked Git, as they occupy similar spaces. Can you list some of the features which Stacked Git has which git-branchless might not?
Sol- 4y ago
We have some people in our company that use tools like Graphite to implement this pattern on top of Github and I don't know if I'm a big fan. Maybe just a matter of developer discipline, but in my experience people tend to create large stacks of 3+ PRs that then take a while to resolve. Yeah sure, without these tools the code would also exist somewhere, but at least you don't have your pull request list full with PRs that aren't yet ready because the upstream PRs haven't been approved yet. You anyways have to (or should) review things stricly serially, so the additional PRs existing are not super useful either. Maybe as context for the reviewer to see the future work. Also for some reason these tools seem to encourage people to put unrelated changes in the stack that could be based directly on master. Probably because they are anyways working on their stack and integrating some unrelated fix they just did into the current stack is easier than rebasing/changing your current context. But that's just a minor pet peeve. That said, I would still like a tool that lets me manage stacked branches just for myself. Not exposing them as Github PRs or so, but to organize my work into different branches. Executing a chain of rebases of branch N -> (N-1) can get quite annoying manually. Probably some arcane git magic to (interactively) rebase branch N->(N-1)->...1 in one command exists already.
- arxanas 4y ago
  > Probably some arcane git magic to (interactively) rebase branch There is not really a command for that yet, short of adding a bunch of `exec` steps to your interactive rebase manually. See https://news.ycombinator.com/item?id=32217204 https://news.ycombinator.com/item?id=32217204 for an upcoming command. You might enjoy using https://github.com/gitext-rs/git-stack https://github.com/gitext-rs/git-stack, which specifically tries to let you manage stacked branches locally while not exposing tons of PRs to your coworkers. git-branchless itself also lets you manage stacked branches in various ways. For example, you can do `git checkout <branch>`, `git commit --amend`, and then `git restack` to rebase all the descendant branches sensibly. You can use it on the local side of things only and then use Github PRs as normal.
  - wakeupcall 4y ago
    Also a big fan of https://gitlab.com/wavexx/git-assembler https://gitlab.com/wavexx/git-assembler (and previously topgit). Works with the basic idea that you can rebuild branches by combining, merging or rebasing automatically on top of others. I frequently use this to build a local branch which is an amalgamation of the main branch + required patches so that I can work (and later submit) on a clean branch without being blocked.
agentultra 4y ago
It depends on the project being worked on. If the main branch changes often enough that you need to merge master before you merge the branch you’ll spend a lot of time propagating changes. And then there’s the problem of large codebases. Without a really good cache strategy for builds all of the branch switching and merging will cause a lot of rebuilds. For some languages and large projects that can be 20+ minutes for a fresh build on each switch. That’s enough time to get distracted by emails or hacker news. I’m a big fan of small commits, often and breaking down changes but it does require a large amount of automation and tooling to support well.
- arxanas 4y ago
  One nice feature of git-branchless (I'm the author) is in-memory rebases. For example, the `git sync` command will rebase all local work on top of the main branch without checking out those branches. (It will also not start merge conflict resolution unless you pass `--merge`, which makes it a lot "safer" to frequently rebase your work.) This helps a lot to avoid invalidating builds.
dboreham 4y ago
Feel the need to observe that we don't need to use PRs at all. Furthermore I see the PR workflow is mostly a cult (which by the way I don't remember anyone asking for -- it seemed to come out of the woodwork either from gitHUB, or from Google). I think it makes some sense in the context of maintenance fixes to a mature release. Perhaps also makes sense in the context of "over the transom" contributions to an OSS project. But for the typical development scenario where most code is green field, and all the developers work in the same organization, it's often just a bad choice of process. So that's why you get to: stacked PRs and whether or not they're good. Rewind to the place where you decided to use PR process in the first place and consider if that was a wise choice.
- endorphine 4y ago
  What's an alternative, considering that you still want co-workers to review your code before you ship it?
sidlls 4y ago
Stacked PRs are an indicator of an incompletely thought out approach to the implementation. Prefer sequential PRs that layer in the implementation: test code, interfaces/API stubs, and then concrete implementations of the stubs (for example). This tends to make PRs less complex and more inviting for colleagues to review, which in my experience tends to make them go much faster. It also leads to generally better code quality.
- hamandcheese 4y ago
  But how can you write the concrete implementation without stacking? The only thing stacked PRs indicate, IMO, is that your coworkers are slow to review your code. And in my experience, when folks send out stacked PRs, it’s because they put much _more_ thought and effort into identifying the right boundaries, not less.
  - WookieRushing 4y ago
    Yup, stacks are wonderful for new features. Typically I run a stack of 5 for new features. First one is the API/interface with null implementations. Then subsequent ones each implement a method with associated tests
raydiatian 4y ago
Here’s a (perhaps) interesting question: has anybody heard of a tool that, given a diff on some state in your codebase, will automatically produce a well organized chain of commits, and/or PRs? As in, “ok tool, here are my files and everything I’ve changed, commit them so that I still have coworkers that think I care about them.” My naive sense is that the knowledge should exist to organize arbitrary code changes in to “good”, “readable”, segments. I mean hell, that’s a whole business right there
hans_castorp 4y ago
> “Pull Request” has a specific meaning in Git Aren't "pull requests" a GitHub (and similar systems) thing? As far as I know, Git itself does not have a concept of "pull requests".
- sebastianz 4y ago
  https://git-scm.com/docs/git-request-pull https://git-scm.com/docs/git-request-pull
  - hans_castorp 4y ago
    Thanks, learned something new today
- morelisp 4y ago
  My memory is fuzzy at this point but I'm pretty sure the command has been named `git-request-pull` as long as it's existed. It actually makes less sense on most forges since there's never an explicit pull step to apply them, assuming you use the forge to do approval.

225 points by kiyanwang 4y ago

I like to do this to address PR feedback, mostly because we use bitbucket, and it's UI for reviewing individual commits sucks.

sandspit 4y ago

Another one: git-town https://www.git-town.com/ https://www.git-town.com/

moffkalast 4y ago

Well this would be impossible to explain and coordinate with the team

catskul2 4y ago
Clearly not the case. A very large number of people use these sorts of flows without problems coordinating or explaining.

rsstack 4y ago

We switched to using https://graphite.dev/ https://graphite.dev/ after yet-another huge epic that caused a mess of PRs and one PR that touched 100+ files and included dozens of semi-related changed. It's been a blessing so far.

zeroonetwothree 4y ago
Graphite is amazing! Would definitely recommend everyone try it at least :)
shepherdjerred 4y ago
How is Graphite? Does it solve the problem of stacked diffs well? I loved the CR tool at Amazon where I could create CRs for arbitrary commit ranges, and I really want to find a similar tool.
thurn 4y ago
Little suspicious of a tool with no pricing information from a company that just raised $20 million. I assume it will not remain free.

rco8786 4y ago

Hope you like merge conflicts and rebase hell as people start to comment and ask for changes

nateroling 4y ago

I’ve played with this idea a bit. In my experience it felt like a hack to work around the fact that individual PRs took a while to get merged. An alternative solve is to work in a way that allows PRs to be merged more quickly, ie pairing, mobbing, or prioritizing getting reviews done asap.

tennis_80 4y ago
Yeah I agree. If you can merge things into a central branch quickly, it’s much better. In my experience with this sort of process you spend quite a lot of time managing your different branches, especially once you start getting feedback and requests for changes. Then keeping everything in sync. Git helps make this quicker but it’s still effort & cognitive load.
avl999 4y ago
It is more about being unblocked than however long it takes for the PR to be merged in even if it is really fast. It is not always possible to pair/mod on a change. Getting folks to quickly review PRs is difficult as doing so breaks the flow state of other people and results in constant thrashing and context switching between the work they are doing are reviewing PRs. Even if the team is committed to quickly reviewing PRs, you are always going to have times when a bunch of people are in a meeting, while a couple are at lunch and a couple are knee deep in another issue and no one can look at your PRs for hours and you need to keep yourself unblocked.

doktorhladnjak 4y ago

We use GitHub Enterprise where I work now. I do sometimes do stacked PRs but GHE does not make it easy. The rebasing and merge conflict resolution can be a headache although git rebase —onto helps a lot. I previously worked somewhere that used Phabricator. Its “stacked diffs” worked great. I’d use it all the time when working on complex, multipart changes.

arxanas 4y ago
Try out the linked tool git-branchless (https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless, I'm the author). It should help you restore Phabricator-like workflows. In particular, check out the `git sync`, `git restack`, and `git move` commands for handling rebasing and conflict resolution.
- doktorhladnjak 4y ago
  Unfortunately I cannot install the rust compiler tool chain or other third party binaries on my work laptop :(
  - tcoff91 4y ago
    You don’t have the ability to install tools on your work computer? That would be a deal breaker for me.

dcow 4y ago

I’m going to be a little crass for a moment: people don’t know how to use their tools! Why are we even talking about “stacked PRs” and “branchless” workflows?! It’s clear the author is documenting their git learning process and that’s great, really. But I’m just surprised how pedantic people get about forcing others to use a tool in a way that caters to their own limited understanding of it. Or, even worse, caters to limitations in the 3rd party UI being used to interface with it (ye ol’ git vs GitHub problem). Learn your tool and then you can worry about the higher order things that are supported by it.

seoaeu 4y ago
This comment would be more compelling if it gave any hint about what aspect of the tooling the author didn’t understand or what they should be doing differently.
- dcow 4y ago
  I’m not talking about the author, specifically or criticizing them directly. I’m lamenting how often I encounter people putting intense amounts of effort into arguing about how git should be used. My hypothesis is that if people understood their tools better before getting all evangelical about forcing their entire eng team to work in their style, others wouldn't have to spend so much time trying to convince them that other styles are exist and are valid. Compare with a construction site: there are obvious uses for tools and there are less obvious uses and I haven't been on a single one where tools are only used specifically in one way for the entirety of the project. They’re used dynamically by different people with different experiences in order to complete the project. Nobody forces other workers to use a specific grip when holding their hammer…
  - johnfn 4y ago
    I'm not understanding how stacking PRs is inconsistent with knowing git well.
    - morelisp 4y ago

is0tope 4y ago

I've usually kept a rule that you should avoid stacking, and if you must only one level deep. The fact that you have to stack in the first place typically suggests that PRs aren't being merged fast enough. Stacking in my personal experience usually leads to merge conflict hell as changes and PR suggestions get merged underneath you.

BerislavLopac 4y ago
My personal rule of thumb is to rebase the working branch as soon as the main has been updated; or at least merge main if the changes are too complex.
ramraj07 4y ago
It’s unavoidable sometimes. I get inspiration and time together rarely, I can’t wait for small chunks of code to be merged before I continue. A lot of times it’s an extremely Productive Sunday afternoon and I have 2500 new lines of code that builds a full new prototype. What am I to do?
- pizza234 4y ago
  I understand that (experienced the same "problem" today), but writing "2500 new lines of code" on a Sunday afternoon is (hopefully) not representative of regular workplace conditions.
  - zeroonetwothree 4y ago
    Some people enjoy their work. I think it’s fine as long as it’s a choice.
    - NateEag 4y ago
      It may be fine. Keep in mind, though, that humans are not perfect and some choices are unwise.
  - ramraj07 4y ago

compsciphd 4y ago

One thing I wish git did (maybe it does and I don't know how?) is to be able to say that a new branch is based off an old branch (not a commit that used to be that branches head). so I can branch a single pr in progress to start the next. Then if I change the base pr in progress (say via rebase or via squashing or the like), I can easily rebase my new commits in the new pr on top of the current state of the branch. Currently, one can just do it by never modifying the underlying "branch" (i.e. just adding new commits), but in practice that doesn't always work, as many times you have to rebase against one's master/main branch to pull in changes, which even if no conflicts, will reflow your "base" branch" changing all the commits. TLDR: Basically, want to be able to state that branch depends on branch (which is currently commit id x) but if I rebase, use whatever the current commit id is for that branch, not whatever it was when I first made the branch. possible? stupid idea? thoughts?

bqmjjx0kac 4y ago
It sounds like you're describing what `git branch --set-upstream-to=$otherBranch` does?
regularjack 4y ago
Isn't that how rebase already works? It will "apply" commits of the current branch onto commits of the base branch, including new commits that were created in the meantime.
theptip 4y ago
This is one of the big features from git-branchless (https://github.com/arxanas/git-branchless/wiki/Command:-git-move https://github.com/arxanas/git-branchless/wiki/Command:-git-...) which is recommended in the article; moving a stack (sub-tree) of commits instead of just one branch. Might be useful for you if you find the rebase flow to be painful. In particular this can be good for local prototyping where you have a bunch of functional candidates on top of some foundational refactors, and you may be rebasing frequently to refine those foundational commits.
- arxanas 4y ago

__derek__ 4y ago

I'm guilty of doing this in the past, but it seems like an anti-pattern because it attempts to create a local optimum, a big no-no in the Theory of Constraints[1]. Better to find ways to sustainably ease the constraint (code reviewers' time/attention) than to find ways to create more WIP at the constraint. [1]: https://en.wikipedia.org/wiki/Theory_of_constraints https://en.wikipedia.org/wiki/Theory_of_constraints

morelisp 4y ago
As someone coming down from a nearly 2 year fight with an engineering manager whose response to every bug was enforcing more code review rules, and every code review backlog was demanding more time allocated for code review, thank you for this comment.
d0mine 4y ago
Could you suggest some specific alternatives?
baq 4y ago
i got a major cognitive dissonance from your comment because stacking PRs is for me the way to get more time and attention from potential reviewers by making their units of work smaller; hopefully small enough to be easily mergable. this is a case of 'more is less' (within reason).
- __derek__ 4y ago
  I'm confused by your "major cognitive dissonance" comment. What you describe appears to reduce variable costs (time spent reviewing) while increasing fixed costs (context-switching). That may increase code reviewer usage, but that doesn't necessarily increase system throughput or reduce WIP.
  - baq 4y ago
    IME it crucially reduces the time a request spends idle waiting for a reviewer, thus increases total throughput.

ramraj07 4y ago

Any UI suggestions to make stacked PRs easier? Other than graphite.dev - that needs org access on GitHub.

stitched2gethr 4y ago
I believe this goes a bit further and decouples the submission from the review. My team reviews PRs very fast, but why should I wait 15 minutes between submitting and continuing my work. Or what about when I'm working late when no one else is online.

surfmike 4y ago

Graphite (https://graphite.dev/ https://graphite.dev/) has been a good tool at our startup to manage stacked PRs, I recommend checking them out.

fallingknife 4y ago

This just shows that people will go to any length to procrastinate PR reviews. The truth is that to be an effective team, reviews need to be highest priority because they are blockers. There is just no way around it.

macintux 4y ago
Any categorical assertion like that feels wrong. Not all projects, all teams, all problems are the same.
- gocartStatue 4y ago
  Lower work in progress generally results in faster & more predictable delivery. PR's are an inventory of "almost finished goods". "Stacking" PR's essentially means delaying integration and increasing WIP.

ridiculous_fish 4y ago

Plugging my own tool: if you like to cultivate a stack of commits, you'll know how awkward git makes it to edit previous commits. With git-prev-next you can run 'git prev 3' and then 'git commit --amend'. https://github.com/ridiculousfish/git-prev-next https://github.com/ridiculousfish/git-prev-next

maxekman 4y ago
`git rebase -i origin/main` (or HEAD~N or any other base) with the e/edit action on selected commit will do the same with only built in functionality.
- ridiculous_fish 4y ago
  Yep, and git-prev-next is built on interactive rebase. It's just a lot faster to run `git prev`, compared to `git rebase -i HEAD^^` and then muck around in a text editor.
arxanas 4y ago
The mentioned tool `git-branchless` (I am the author) also supports `git prev 3` followed by `git commit --amend`. See https://github.com/arxanas/git-branchless/wiki/Command:-git-next,-git-prev https://github.com/arxanas/git-branchless/wiki/Command:-git-...

yosito 4y ago

This article uses the term DAG everywhere, but I couldn't find a definition of it.

scruple 4y ago
Directed Acyclic Graph. [0]: https://en.wikipedia.org/wiki/Directed_acyclic_graph https://en.wikipedia.org/wiki/Directed_acyclic_graph

avl999 4y ago

I do stacked PRs at work, they work great until someone suggests an invasive change in a PR lower down in the stack. Does anyone have ideas on how to deal with merge conflicts in this type of flow? For example let's say I have the following stack of PRs PR1 -> PR2 -> PR3 -> PR4 The reviewer reviews and suggests a change in PR1, this change causes a merge conflict in PR2 and therefore in PR3 and PR4 as well. And then you have to go in manually resolve the exact same merge conflict all the way through you PR stack in each of the PRs. This gets annoying and hard to work with. Does anyone have a better way of dealing with this pattern of merge conflict? I've tried using git rerere which in theory sounds helpful but doesn't seem to do anything when I strike this issue.

fire 4y ago
huh, shouldn't solving the conflict to pr2 create a merge commit that then also solves the conflict in 3 and 4?
- travisb 4y ago
  It sounds like the OP might be using a rebase workflow. Such a workflow creates many repetitive conflicts because there is no merge commit to record the resolution point. Using a rebase workflow with stacked/cascaded PRs is an anti-pattern that trips up people used to other git workflows where the history depth is effectively only one level deep instead of arbitrarily deep as in stacked/cascaded PRs.
  - xerxes901 4y ago
    I think this is something git rerere is supposed to help with
  - anderskaseorg 4y ago
    You can tell git what the resolution point is using `git rebase --onto`. This can help avoid situations where Git gives extra conflicts form trying to reapply an old version of your change on top of a new version of the same change. You can also use `git rebase --skip` if you recognize that you’ve ended up in this situation.

krooj 4y ago

I've tried this method of taking a large change and breaking it up into smaller, more easily digestible PRs, and it didn't work. Unless you're working with folks that are directly invested in the change, you'll very quickly discover that people have memories worse than goldfish. So, it's a lose-lose situation: can't really do stacked PRs and large PRs will let bugs and other defects through.

avl999 4y ago
There is a tradeoff... smaller, digestible PRs result in thorougher and faster reviews but it gives up the "1000 feet view" of the larger feature as far as the reviewer is concerned. Large PRs preserve the larger "1000 feet view" of what you are working on but are likely to be slower to get responses on and most likely less thorough thus a larger chance of things being missed. Almost everyone I've worked with prefers smaller review so I just accept that trade-off of 1
culi 4y ago
Can't this easily be resolved by just using feature branches? Make your small PRs into the feature branch but then you still have the ability to compare the branch to main as a whole and get that wider context

jasonhansel 4y ago

Why not just break up your change into small components, then merge each one into master separately, hiding the change behind a feature flag until the whole thing is done?

travisb 4y ago
Your suggestion comes after the changes are merged. That is, you wouldn't normally merge anything to master without having it reviewed. Stacked PRs is _how_ you can break up your changes into small components to merge more quickly and block development less. With stacked PRs the changes are broken into smaller pieces because a later PR can depend on an earlier PR. This means it can be developed while earlier PRs are still under review. It also means each review is smaller and therefore likely to complete more quickly. Stacked PRs can also work like patch series in the Linux Kernel development where a large change is broken into smaller independent changes done in the logical order, even if their order of discovery was probably reverse. For example, if you discover you need a refactor or bug fix while halfway through developing a feature. In that case you simply insert a PR earlier in the stack/graph which contains just that isolated fix. In your feature flag example, a common patten would be to have a dozen or so stacked PRs. The early ones do necessary refactors and bug fixes. The middle few add the feature flag and code. The last make the feature flag the default and delete the now obsolete !feature path. Then the prereqequites (which you didn't discover until half-way through) can be reviewed and merged quickly. The meat of the feature is broken up into easily digestible pieces for quick review, but reviewers can get a sense of the entire feature by considering the PR series as a whole; this is especially useful where one PR adds some infrastructure that a later PR uses but both PRs together would be too large to effectively review. As PRs are ready to merge, they can. Often the last couple of PRs which make the feature the default and delete the obsolete code do not merge for quite some time, but they were written when everything was still fresh in the developers head.

jackblemming 4y ago

There's so many articles on trivial things like this and using pretty syntax and less articles on things that actual matter: architecture and design. It's a bit disheartening to hear software engineers argue of if you should put periods in commit titles or if so and so syntax is more readable.

catskul2 4y ago
Not at all trivial. If it seems that way to you, then it's likely that you simply haven't worked on a project with the scale and workflows which require this.
- jackblemming 4y ago
  Have you considered large successful software projects have been done without any of these modern tools or languages? Or are your projects more complicated than the moon landing?
  - catskul2 4y ago
    You seem to be arguing any tools and languages made after the moon landing are trivial unless the project is "more complicated than the moon landing". Is that the argument intended to make?

TazeTSchnitzel 4y ago

Stacked reviews is a very natural pattern if you're using a system like Gerrit, where the unit of review is not a whole branch, but individual commits. Since they are commits, the reviews can have any kind of relationship that commits can have. I think it's a great system, including for some other reasons (it encourages amending and rebasing commits during the review process, which results in a very clean git history). After using Gerrit professionally for several years I wonder how I ever lived with GitHub-style pull requests.

baq 4y ago
github pull request review process, UI and the whole experience is very much the worst thing about github for me. there's literally one feature that I like (C-g, suggest a one-click committable change in a comment) and everything else is better in gerrit.
dimal 4y ago
How is reviewing individual commits a good thing? Maybe I’m misunderstanding something, but my branches have tons of micro commits that ultimately lead to a larger change. Reviewing each individual commit in that type of branch seems like it would be very tedious, and not useful. The reviewer would be forced to follow my entire process, with all the dead ends and refactors along the way. Seems like it would take a lot longer. Or is there another workflow that I’m not seeing?
- dodobirdlord 4y ago
  Squash your commits once you've finished prior to sending them for review? Code review of individual commits generally stems from a workflow that expects that each individual commit will contain a change that is complete in and of itself, along with the corresponding tests for that change, so that the project builds and all tests pass at every commit. This makes exploring the change history easier and reverting changes cleaner, and simplifies bisecting the commit history.
- Groxx 4y ago
  With this sort of system you generally squash your commits together to form one-per-reviewable-thing. Or at least you rewrite things a bit to make it approachable. E.g. I split things apart so one commit is an obviously-correct refactor and the later ones are pure changes. I understand some of the "no, merges are superior because they retain all history" proponents (not claiming you are one, just aiming to head off that flood), but all those dead ends and refactors along the way are just those - dead ends and refactors. They ruin the ability to bisect, for instance, because they are rarely all functional. Intentional commits, like a stacked workflow supports in a tool like Gerrit, lets you have a wonderfully understandable history that works at every point.

arxanas 4y ago

I am the author of the linked tool git-branchless. Happy to answer any questions about stacked PR workflows here or on GitHub discussions https://github.com/arxanas/git-branchless/discussions https://github.com/arxanas/git-branchless/discussions or Discord https://discord.gg/caYQBJ82A4 https://discord.gg/caYQBJ82A4.

tomasreimers 4y ago

I am one of the authors of the tool Graphite (https://graphite.dev https://graphite.dev). We built Graphite because we missed the stack diff workflow we knew from previous job experiences at larger companies, happy to answer any questions (and if you would rather not ask in public, feel free to email me at tomas at graphite.dev).

shepherdjerred 4y ago
How much team buy-in does this require? Would everyone on my team need to use Graphite, or could they continue to use GitHubs code review if they prefer?
- presentation 4y ago
  I tried it, requires no buy in, pretty much everything still properly shows up in GitHub.
  - shepherdjerred 4y ago
    Okay, I watched this video[0] and I'm sold! I'm going to try it out myself, and it seems like my co-workers wouldn't even have to know that I'm using it. Of course, if it works well I'll definitely advocate for it! [0]: https://www.youtube.com/watch?v=cE59cfwWL7M https://www.youtube.com/watch?v=cE59cfwWL7M

davvid 4y ago

There is active work related to teaching "git rebase" to natively support stacked branches in the Git core currently being worked on by Derrick Stolee [1]. If you "stack" your changes across multiple inter-dependent branches it looks like "git rebase" is going to learn how to update related branches using a new "update-ref" command (alongside "squash", "fixup", "exec", etc) that gets activated automatically through a "git rebase --update-refs" command-line flag and config option. (This is from Derrick, not me) """ This is a feature I've wanted for quite a while. When working on the sparse index topic, I created a long RFC that actually broke into three topics for full review upstream. These topics were sequential, so any feedback on an earlier one required updates to the later ones. I would work on the full feature and use interactive rebase to update the full list of commits. However, I would need to update the branches pointing to those sub-topics. This series adds a new --update-refs option to 'git rebase' (along with a rebase.updateRefs config option) that adds 'git update-ref' commands into the TODO list. This is powered by the commit decoration machinery. """ This is under active development (I don't believe the topic has been merged yet) so it's still open for feedback and refinement on the git development mailing list. Thanks Derrick! [1] https://public-inbox.org/git/pull.1247.git.1654263472.gitgitgadget@gmail.com/ https://public-inbox.org/git/pull.1247.git.1654263472.gitgit...

hinkley 4y ago
Is that likely to help with permanent forks or will that still continue to be an issue?
timhh 4y ago
That sounds great! I have partly solved this issue in my autorebase tool (https://github.com/Timmmm/autorebase https://github.com/Timmmm/autorebase) - it basically rebases every branch, and fixes the commit time so that stacked branches get preserved even after a rebase just because the hashes all match properly. That obviously doesn't work if you modify or drop any of the commits, so this option is very welcome!
shepherdjerred 4y ago
This would be such a great addition! It doesn’t get stacked diffs to quite native support within Git, but it’d be a very good step in that direction

loloquwowndueo 4y ago

Bzr has a pipelines plug-in which does basically this. Branches can be stacked on top of each other forming a “pipeline”, and propagating changes from one branch to the dependent / subsequent ones is achieved with one command, “bzr pump”. Bzr has no concept of rebasing, so what you get is a simple merge, but with very little work on your part.

somehnacct3757 4y ago

I like to figure out what all my PRs will be during the planning phase, optimizing for reviewer cognitive load and incremental development of shippable features. I never need to stack PRs cuz I can work on the next one while the first one is under review and rebase once it's merged. I can see if the review phase is long at your company that this wouldn't work. But I prefer it if possible. One thing I hate about stacked PR delivery is ppl go dark for a month building this whole new world and if you have architecture concerns in the root PR they will resist them because it means rebasing and changing all the downstream PRs as well. Bad incentives all around.

arxanas 4y ago
You might be interested in https://github.com/gitext-rs/git-stack https://github.com/gitext-rs/git-stack, which perfectly implements your workflow where you only put up one PR but continue to work locally on the next commits. > ppl go dark for a month building this whole new world I think this isn't specific to stacking PRs. You can put 100 commits in a PR and submit it at once, or you can make 100 PRs and submit them all at once, and have the same problems either way. Ideally, you put up your first few commits or PRs early so that they can get reviewed.

tunesmith 4y ago

How would you align this with Jira stories? Our team tries to maintain a one-PR-per-story flow. Partly for QA purposes, we don't want multiple QA cycles per story. Of course, we still have giant PRs that touch 50-100 files and take forever to code review. And yet, for those stories in question, they do make it to prod faster than if they were broken apart into multiple 1-2 point stories. I imagine as always the answer is "invest in better tooling". More robust automated tests, push-button millisecond-deployments, etc...

arxanas 4y ago
Basically: you don't :) I've only ever found this workflow to work if you can attach multiple commits/code reviews to single higher-level work items in your project management software. There's simply too much overhead if you try to correlate project management items one-to-one with commits/code reviews.

bvrmn 4y ago

Mentioned tools seem highly underfeatured comparing with stacked git[1]. [1] https://stacked-git.github.io/ https://stacked-git.github.io/

arxanas 4y ago
Hi bvrmn, I've been meaning to write a comparison of git-branchless with Stacked Git, as they occupy similar spaces. Can you list some of the features which Stacked Git has which git-branchless might not?

Sol- 4y ago

We have some people in our company that use tools like Graphite to implement this pattern on top of Github and I don't know if I'm a big fan. Maybe just a matter of developer discipline, but in my experience people tend to create large stacks of 3+ PRs that then take a while to resolve. Yeah sure, without these tools the code would also exist somewhere, but at least you don't have your pull request list full with PRs that aren't yet ready because the upstream PRs haven't been approved yet. You anyways have to (or should) review things stricly serially, so the additional PRs existing are not super useful either. Maybe as context for the reviewer to see the future work. Also for some reason these tools seem to encourage people to put unrelated changes in the stack that could be based directly on master. Probably because they are anyways working on their stack and integrating some unrelated fix they just did into the current stack is easier than rebasing/changing your current context. But that's just a minor pet peeve. That said, I would still like a tool that lets me manage stacked branches just for myself. Not exposing them as Github PRs or so, but to organize my work into different branches. Executing a chain of rebases of branch N -> (N-1) can get quite annoying manually. Probably some arcane git magic to (interactively) rebase branch N->(N-1)->...1 in one command exists already.

arxanas 4y ago
> Probably some arcane git magic to (interactively) rebase branch There is not really a command for that yet, short of adding a bunch of `exec` steps to your interactive rebase manually. See https://news.ycombinator.com/item?id=32217204 https://news.ycombinator.com/item?id=32217204 for an upcoming command. You might enjoy using https://github.com/gitext-rs/git-stack https://github.com/gitext-rs/git-stack, which specifically tries to let you manage stacked branches locally while not exposing tons of PRs to your coworkers. git-branchless itself also lets you manage stacked branches in various ways. For example, you can do `git checkout <branch>`, `git commit --amend`, and then `git restack` to rebase all the descendant branches sensibly. You can use it on the local side of things only and then use Github PRs as normal.
- wakeupcall 4y ago
  Also a big fan of https://gitlab.com/wavexx/git-assembler https://gitlab.com/wavexx/git-assembler (and previously topgit). Works with the basic idea that you can rebuild branches by combining, merging or rebasing automatically on top of others. I frequently use this to build a local branch which is an amalgamation of the main branch + required patches so that I can work (and later submit) on a clean branch without being blocked.

agentultra 4y ago

It depends on the project being worked on. If the main branch changes often enough that you need to merge master before you merge the branch you’ll spend a lot of time propagating changes. And then there’s the problem of large codebases. Without a really good cache strategy for builds all of the branch switching and merging will cause a lot of rebuilds. For some languages and large projects that can be 20+ minutes for a fresh build on each switch. That’s enough time to get distracted by emails or hacker news. I’m a big fan of small commits, often and breaking down changes but it does require a large amount of automation and tooling to support well.

arxanas 4y ago
One nice feature of git-branchless (I'm the author) is in-memory rebases. For example, the `git sync` command will rebase all local work on top of the main branch without checking out those branches. (It will also not start merge conflict resolution unless you pass `--merge`, which makes it a lot "safer" to frequently rebase your work.) This helps a lot to avoid invalidating builds.

dboreham 4y ago

Feel the need to observe that we don't need to use PRs at all. Furthermore I see the PR workflow is mostly a cult (which by the way I don't remember anyone asking for -- it seemed to come out of the woodwork either from gitHUB, or from Google). I think it makes some sense in the context of maintenance fixes to a mature release. Perhaps also makes sense in the context of "over the transom" contributions to an OSS project. But for the typical development scenario where most code is green field, and all the developers work in the same organization, it's often just a bad choice of process. So that's why you get to: stacked PRs and whether or not they're good. Rewind to the place where you decided to use PR process in the first place and consider if that was a wise choice.

endorphine 4y ago
What's an alternative, considering that you still want co-workers to review your code before you ship it?

sidlls 4y ago

Stacked PRs are an indicator of an incompletely thought out approach to the implementation. Prefer sequential PRs that layer in the implementation: test code, interfaces/API stubs, and then concrete implementations of the stubs (for example). This tends to make PRs less complex and more inviting for colleagues to review, which in my experience tends to make them go much faster. It also leads to generally better code quality.

hamandcheese 4y ago
But how can you write the concrete implementation without stacking? The only thing stacked PRs indicate, IMO, is that your coworkers are slow to review your code. And in my experience, when folks send out stacked PRs, it’s because they put much _more_ thought and effort into identifying the right boundaries, not less.
- WookieRushing 4y ago
  Yup, stacks are wonderful for new features. Typically I run a stack of 5 for new features. First one is the API/interface with null implementations. Then subsequent ones each implement a method with associated tests

raydiatian 4y ago

Here’s a (perhaps) interesting question: has anybody heard of a tool that, given a diff on some state in your codebase, will automatically produce a well organized chain of commits, and/or PRs? As in, “ok tool, here are my files and everything I’ve changed, commit them so that I still have coworkers that think I care about them.” My naive sense is that the knowledge should exist to organize arbitrary code changes in to “good”, “readable”, segments. I mean hell, that’s a whole business right there

hans_castorp 4y ago

> “Pull Request” has a specific meaning in Git Aren't "pull requests" a GitHub (and similar systems) thing? As far as I know, Git itself does not have a concept of "pull requests".

sebastianz 4y ago
https://git-scm.com/docs/git-request-pull https://git-scm.com/docs/git-request-pull
- hans_castorp 4y ago
  Thanks, learned something new today
morelisp 4y ago
My memory is fuzzy at this point but I'm pretty sure the command has been named `git-request-pull` as long as it's existed. It actually makes less sense on most forges since there's never an explicit pull step to apply them, assuming you use the forge to do approval.