Hacker News Reader

Comment by ISO-morphism | Hacker News Reader

There are two solutions that come to my mind, both are more by convention:

1. Always use merge commits (--no-ff) a la git flow, and leave the branch name in the merge commit. That doesn't get you the branch name on the commit, but it should help identify the branches.

2. Use a pre-commit hook to put the branch name or bug tracker ID at the bottom of the commit message. There are some tools built around this, I've done it at $DAYJOB with a custom python script I manually copy around into `.git/hooks/pre-commit`.

View on HN

Good solutions. FF/rebase are very nice, but I've seen devs sleuth into a squashed PR commit, find the PR the features came from and read it on GH, and that's powerful.

I saw a new dev do this recently. They dug into the original summary of the changes from the dev (for a PR that landed 6 months before they joined) and the flow of conversation around the work. They had insights into the decisions the team made around the feature as it was developed. The PR linked to the product artifacts that led to the work, so they had the business context. They nailed the implementation, first time :-)

There's a nice benefit to doing merge/squash and providing a link to a set of context around the specific set of commits, not just a contextless line of commits, as clean as it may be.

As a variant of option 2, could one create a new tag at the pre-merge commit?

We do exactly that. If you are on the main branch and merge "feature/my-feature", we use an bash script to create a annotated tag called "integrated/my-feature" which replaces the feature branch. So on our clients it looks like we have a tag folder "integrated" with all previous branch names.

Git merge does something pretty awful; it takes multiple changes and turns them into a single patch bomb in the destination branch.

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.

You need all 17 commits, in their rebased versions, on master, so you can search through their history (e.g. with git bisect) and discover that the 9th one broke it.

Rebase is the correct thing: it calculates a new sequence of commits that are individually merged, and retained as separate commits that you can dig through in the new branch.

What's missing is this: the rebase of an entire branch into a new branch should record a second commit parent (for the final commit of the operation), pointing to the final commit of the original branch.

Like this:

          X-Y-Z--<< branch
         /
   -A-B-C-D-E--<< master

rebase it:

           X-Y-Z--<< branch
          /     \___
         /          \
   -A-B-C-D-E-X'-Y'-Z'---<< master

where X', Y', Z' are the rebased versions of X, Y, Z.

A regular git rebase is missing that second parent link from Z' to Z. You just get this:

           X-Y-Z--<< branch
          /
         /
   -A-B-C-D-E-X'-Y'-Z'---<< master

The only way you can identify that Z' was cherry-picked from Z is by clues in the commit message: identical commit message text, or something like a Gerrit Change-Id.

Possibly, each cherry-picked commit should have the original as its parent:

           X-Y-Z--<< branch
          / \_\_\___
         /    \  \  \
   -A-B-C-D-E-X'-Y'-Z'---<< master

now that is almost like iterating over the branch and doing a commit-by-commit merge.

At first we pretend that the branch is just X, and merge it to get X'. Then we merge Y', and then Z'. We never merge a sequence of two or more commits into one.

If you do that, you have both: nobody can say you're not merging, but you have the effect of a rebase.

A rebase (cherry-pick) is a kid of merge: of one commit (at a time), without recording all the parents.

A case can be made for rebasing commit-at-at-time using merge. (Not for private work, obviously; just already published, permanent history).

The nice thing about rebase is that it doesn't introduce the crufty parentage, which makes it ideal for rearranging unpublished history and then presenting a clutter-free end result.

> 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.

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).

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.

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.

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?

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?

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.

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.

> it's also just turns PRs/branches into commits and is effectively a single-branch linear workflow

Yes! This is ideal.

> 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.

Reply on news.ycombinator.com