Git

2903 readers

1 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

Follow programming.dev rules
Be excellent to each other, no hostility towards users for any reason
No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago

MODERATORS

Ategon

canpolat

jnovinger

Git Patch Stack Goals (engineering.uptechstudio.com)

submitted 1 year ago by drewdeponte to c/git

4 comments fedilink hide all child comments

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

top 4 comments

sorted by: hot top controversial new old

[–] tatterdemalion 5 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] drewdeponte 1 points 11 months ago

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

Yes, sorry. The post doesn't provide the full context as it is just a post covering the goals of Git Patch Stack.

Git Patch Stack is a tool that works with Git to facilitate a "Patch Stack" based workflow in a manner that also maps seemlessly to the Feature Branch/Pull Request model of GitHub, Bitbucket, GitLab, etc. that the majority of the development communities use. https://git-ps.sh is the official website for it. https://github.com/uptech/git-ps-rs is the repository.

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.

Thanks for the feedback abound rambling. In relation to stgit Git Patch Stack is a bit different as it tries to really facilitate Git and doesn't have any internal state it tracks (previous versions did). Now it is really more of just a different way of viewing the state of the Git tree in a way that makes sense in terms of a "Patch Stack" based workflow. I think it also differs in that it is trying to be companion app to Git so that a user can and should use both Git and Git Patch Stack together. Git Patch Stack also tries to align the commands as much as possible around normal git concepts and commands.

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.

The "Stacked Branch" workflow is a different workflow than "Patch Stack" based workflow. I agree with you that you shouldn't want to manage branches or the relations between. That is why the "Patch Stack" based workflow that Git Patch Stack facilitates eliminates this. However, there are a lot of people out there that are using a "Stacked Branch" based workflow and tooling around it like https://graphite.dev that do manage branches for each atomic commit and building a DAG (directed acyclic graph) defining their relationships so that their tooling can do things like automate rebasing, etc.

[–] aport 3 points 1 year ago* (last edited 1 year ago) (1 children)

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 1 points 11 months 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.