14 ms·

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

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.
- preseinger 5y ago
  I'm clearly failing to communicate my intent here :) If I don't treat a commit as a meaningful layer of abstraction, then it isn't one. If I say a commit isn't meaningful then it isn't; Git's semantics are secondary to mine. Right? Is this controversial?
  - CRConrad 5y ago
    Yes, seems to me it is controversial if you then also complain about not being able to see exactly where -- in which commit -- some breaking change happened. Doesn't that mean commits are actually meaningful to you; why else would that be what you're looking for?
    - preseinger 5y ago
      Commits aren't meaningful to me. Breaking changes are properties of PRs, not commits. But I basically never care about breaking changes, because they shouldn't ever get merged to main. CI should have prevented that outcome.

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.

preseinger 5y ago
I'm clearly failing to communicate my intent here :) If I don't treat a commit as a meaningful layer of abstraction, then it isn't one. If I say a commit isn't meaningful then it isn't; Git's semantics are secondary to mine. Right? Is this controversial?
- CRConrad 5y ago
  Yes, seems to me it is controversial if you then also complain about not being able to see exactly where -- in which commit -- some breaking change happened. Doesn't that mean commits are actually meaningful to you; why else would that be what you're looking for?
  - preseinger 5y ago
    Commits aren't meaningful to me. Breaking changes are properties of PRs, not commits. But I basically never care about breaking changes, because they shouldn't ever get merged to main. CI should have prevented that outcome.