this post was submitted on 10 Nov 2023
5 points (100.0% liked)

Git

2904 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

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. 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
5
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.

you are viewing a single comment's thread
view the rest of the comments
[–] 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.