4 ms·

> What if the branch has 17 commits, the 9th of which introduces a regression? Moreover, suppose that the 9th commit of the original branch didn't exhibit the r

> What if the branch has 17 commits, the 9th of which introduces a regression? Moreover, suppose that the 9th commit of the original branch didn't exhibit the regression; rather, its change had that effect when it was merged into master. For some developers, the commit is the cohesive unit of change. For others, the PR as a whole is the cohesive unit of change. I fall into the second group. The ninth commit of my branch is meaningless -- it's only the branch as a whole which can be understood as a single coherent thing. Squash merges reflect and support my methodology.

Spivak 5y ago
I also have found myself in a shop that uses this flow, and don't get me wrong, it works pretty darn well, but it's also just turns PRs/branches into commits and is effectively a single-branch linear workflow with extra steps. It's the closest thing to not using git that exists.
- preseinger 5y ago
  > it's also just turns PRs/branches into commits and is effectively a single-branch linear workflow Yes! This is ideal.
- w-j-w 5y ago
  This is Continuous Integration or Trunk Based development, and it often shows up in surveys as being a very effective tactic.
- hn_throwaway_99 5y ago
  > It's the closest thing to not using git that exists. Totally disagree, because the whole reason for this is to support multiple developers working simultaneously of the same master branch. That is, sure, master may just be a linear history of commits, but at any specific point in time there may be 10 feature branches off master, each from a different branch point.
kazinator 5y ago
Factually, the commit is the unit of change. (Gitwise-factually, a commit is a snapshot, not a change, but a new snapshot represents a change relative to some other snapshot, like any one of its indicated parents.) Your "methodology" is not rooted in facts. It can be described as wanting every version control to be CVS. Back in the day when those kinds of systems were widely used, the most common complaint from knowledgeable CM people was that there are no change sets: related sets of changes treated as a unit which contains the fine-grained changes, with individual descriptions, references to tickets and so on. If we regard a feature branch as a change set, when you do a squashing merge in git, you're vandalizing the change set; the merge you're doing is only slightly better than "cvs -j from -j to" (merge the delta between from and to onto the working copy). How it's slightly better is that it records the extra parents, for tracking. One of the main improvements in git over things like CVS and Subversion is that you can at least halfway simulate change sets, due to the relative ease of manipulating individual commits and the scripting done around it (like git rebase scripted around cherry-pick).
- preseinger 5y ago
  I think we're just speaking at different levels of abstraction. I agree that, concretely, a commit is a Git domain concept that signifies a unit of change, and has certain properties and relationships to other domain concepts. But in the context of my project, I get to assign whatever semantics I want to that lower-level concept. So a commit for me is more of a time-based snapshot of my work in progress, rather than a single unit of software or project change. That's what I'm speaking to. > If we regard a feature branch as a change set, when you do a squashing merge in git, you're vandalizing the change set I'm not. The change set is atomic, the individual commits are essentially implementation details which the PR encapsulates, and when it's merged to main those details become opaque. I mean this is just my methodology, it doesn't have to work for everyone but it's the natural expression of my work for me.
  - kazinator 5y ago
    Yes, there are different levels of chunking we can consider: a branch is a change, and a commit is a change. Be that as it may, a squashing merge is focused on one level of abstraction and mostly poops over the others. The nice thing about levels of abstraction is that we can have them all and preserve them. Commits which you did not actually produce as part of a merge are not an implementation detail; something which isn't there does not provide implementation. Opaque implementation details are something which exists; they can be looked at debugged into.

Spivak 5y ago

I also have found myself in a shop that uses this flow, and don't get me wrong, it works pretty darn well, but it's also just turns PRs/branches into commits and is effectively a single-branch linear workflow with extra steps. It's the closest thing to not using git that exists.

preseinger 5y ago
> it's also just turns PRs/branches into commits and is effectively a single-branch linear workflow Yes! This is ideal.
w-j-w 5y ago
This is Continuous Integration or Trunk Based development, and it often shows up in surveys as being a very effective tactic.
hn_throwaway_99 5y ago
> It's the closest thing to not using git that exists. Totally disagree, because the whole reason for this is to support multiple developers working simultaneously of the same master branch. That is, sure, master may just be a linear history of commits, but at any specific point in time there may be 10 feature branches off master, each from a different branch point.

kazinator 5y ago

Factually, the commit is the unit of change. (Gitwise-factually, a commit is a snapshot, not a change, but a new snapshot represents a change relative to some other snapshot, like any one of its indicated parents.) Your "methodology" is not rooted in facts. It can be described as wanting every version control to be CVS. Back in the day when those kinds of systems were widely used, the most common complaint from knowledgeable CM people was that there are no change sets: related sets of changes treated as a unit which contains the fine-grained changes, with individual descriptions, references to tickets and so on. If we regard a feature branch as a change set, when you do a squashing merge in git, you're vandalizing the change set; the merge you're doing is only slightly better than "cvs -j from -j to" (merge the delta between from and to onto the working copy). How it's slightly better is that it records the extra parents, for tracking. One of the main improvements in git over things like CVS and Subversion is that you can at least halfway simulate change sets, due to the relative ease of manipulating individual commits and the scripting done around it (like git rebase scripted around cherry-pick).

preseinger 5y ago
I think we're just speaking at different levels of abstraction. I agree that, concretely, a commit is a Git domain concept that signifies a unit of change, and has certain properties and relationships to other domain concepts. But in the context of my project, I get to assign whatever semantics I want to that lower-level concept. So a commit for me is more of a time-based snapshot of my work in progress, rather than a single unit of software or project change. That's what I'm speaking to. > If we regard a feature branch as a change set, when you do a squashing merge in git, you're vandalizing the change set I'm not. The change set is atomic, the individual commits are essentially implementation details which the PR encapsulates, and when it's merged to main those details become opaque. I mean this is just my methodology, it doesn't have to work for everyone but it's the natural expression of my work for me.
- kazinator 5y ago
  Yes, there are different levels of chunking we can consider: a branch is a change, and a commit is a change. Be that as it may, a squashing merge is focused on one level of abstraction and mostly poops over the others. The nice thing about levels of abstraction is that we can have them all and preserve them. Commits which you did not actually produce as part of a merge are not an implementation detail; something which isn't there does not provide implementation. Opaque implementation details are something which exists; they can be looked at debugged into.