drewdeponte

Actually, having more commits is negligible because of the way that Git stores the snapshots behind the scenes. Specifically, it uses a content addressable key value store. So the storage is bound to the file changes irrespective of the commits.

The commits simply hold the sha of each of the files. Technically, it is a bit more complicated than that. But from an understanding of size implications and what it is bound to that mental model should get you there. It also does additional smart things in packing this key value store to store things more efficiently that also help.

If you want to start understanding more about the internals of kid and how it actually stores stuff. The Pro Git book has a Git Internals section, https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain which is a great place to start.

What is important to me is that when you open a pull request the commits in that pull request, the things you are requesting to be brought into the mainline, are in a good and final form. Meaning they are actually ready to be brought into mainline. That means each of them need to be logically chunked, clearly define and communicate the intent, etc. as I outlined in the article.

Now, prior to that moment in time where you open the pull request. You can have your commits look like whatever horrible mess you want locally. Including if they are in a branch that you want locally that you aren’t going to integrate into mainline or open a pull request for.

To facilitate this refinement of commits prior to this moment of opening a pull request. I personally use interactive rebase a lot as well as use https://git-ps.sh/ to facilitate a patch stack based workflow locally.

I have found that organizing my commits according to the principles outlined in the article is extremely valuable even locally. It seems like most devs aren’t comfortable enough with git interactive rebase, etc. that facilitate refining commits as you go along. This is simply a skill issue that is well worth learning.

If you take the stance in which you say it is my PR. Whatever commits are in there are whatever commits you created, with no logical separation, no clear commit descriptions explaining the intent of each of the changes you made. You then lose the benefits outlined in the article. Tools like git bisect won’t work properly, reverting commits sucks, etc.

If you say, well what if we use GitHub to require that PR be integrated using a Squash & Merge? You still end up losing almost all of the benefits.

So I think the dividing line needs to be that if you are requesting something to be integrated into mainline, or you are going to integrate something into mainline, you should follow the principles in the article. Otherwise, you are just taking the stance that you don’t care about the values outlined in the article.

Which is a stance you can take. But those values being present or not based on your position is not opinion. That is fact, as it is provable by you simply testing out the things. So be careful not to fall into the trap of being like, “Well that is your opinion.”, and missing out on the fact that by having a different opinion you are factually losing out on the benefits.

In the example I provide the project that the PR was made for doesn’t have the linting passing as a build requirement. But that is irrelevant to the point I am trying to make which is to split things out base on those singular intents. Do you think that point was clear?

Maybe I should change the example so that it isn’t based on linting which can be part of the build requirements but doesn’t have to be.

First of thanks so much for the feedback. I very much appreciate it.

Conventional commit messages is something that I was contemplating putting in there. Though I consider it less of a core thing and more a layer that you can add on once you have the core stuff. I alluded to it in the following.

There are many more things you can include in your commit messages and the template to help you. Some people add explicit change log entries to their commit messages that are targeted at the consumers of the product rather than the developers. Others manage sign-off from peer developers through commit message standards they have defined, etc.

In my opinion, all these things can be valuable, and should be considered, but the above template really outlines the core that should always be present.

The Consistent imperative form is something I do follow and just forgot to put it there. I will have to figure out a way to work Consistent Imperative Form in there fully and Conventional Commits linked in that section I quoted above as an example. So people are at least able to go look into it further themselves.

Thanks again.

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.

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.