Git Patch Stack Goals | Uptech Studio - Engineering
engineering.uptechstudio.com
An exploration of the goals and intent behind the Git Patch Stack project.

Audio and transcript of a discussion of the goals and intent of the Git Patch Stack project.

  • tatterdemalion@programming.dev
    5·
    1 year ago

    OK but what is “Git Patch Stacks”? It seems like I’m missing something fundamental that was never actually explained in this post.

    EDIT: Oh hey I found it after reading a different blog post on that site: https://github.com/uptech/git-ps-rs

    The post is also super rambling in the middle section.

    I have to assume that this is something similar to Mercurial’s MQ plugin or Stacked Git (stgit), which allow you to manage revisions as a stack of diffs.

    I personally enjoy using stgit, and it fits just fine into the world of feature branches and PRs.

    This part scared me:

    In a Stacked Branch workflow, you are creating branches for each of your atomic commits, and then you’re defining the relationships between those branches so it can formally store a directed acyclic graph of those relationships.

    Why do you want to make a separate branch for every commit? That sounds like a nightmare, and it’s definitely not the intended workflow for git.

  • aport@programming.dev
    3·
    1 year ago

    Tbh this sounds like a solution in search of a problem. Ain’t nobody got time to learn some new workflow with associated helper scripts which in the end provide questionable value, if any at all.

    If working with queues of patches on a trunk based workflow is your jam then try Gerrit

    • drewdeponte@programming.devOP
      1·
      1 year ago

      That is actually one of the main points of Git Patch Stack. Gerrit which does support a trunk based workflow of patches similarly. It however requires a completely new set of tooling both on the client and the server side of things. So your team needs to switch to a different SCM platform which isn’t GitHub, GitLab, or Bitbucket, etc. Which means adoption requires an entire team to do a massive switch.

      Git Patch Stack on the other hand provides the trunk based workflow while still allowing the user to use Git however they might want, and also interact with the feature branch/pull request model of GitHub, Bitbucket, GitLab, etc. So each dev can locally do what makes sense for them rather than having to get entire team to migrate over to something like Gerrit. Also it doesn’t have any additional state creation. It just provides a meaningful view of the Git tree in a way that makes sense for the trunk based workflow, as well as additional commands to make operating conceptually in that world make more sense. So it makes it easy for people to have hybrid workflows or adopt the workflow over time, etc.