Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trunk Based Development

trunkbaseddevelopment.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Trunk Based Development

#41

Post by ahartmetz »

groestl wrote: post #25
aidos wrote: post #22

Earlier quoted context omitted.

It’s pretty hard to keep the commits in a working branch in a good legible state - certainly it takes work to do it. In 25 years of professional development I’ve never really had a situation where the commits on a branch would have helped me understand what was going on a year ago when the work was done. That includes pretty big bits of project work. I’d much rather have a trunk with commits at the granularity of fea…

100%. I don't want to know how the sausage was made. It's similar to research papers, or history books, where the way we arrive at results or outcomes in the real world is often quite different from the way it's presented in the final form.

A good commit history is more like a well-written sausage recipe than like a TV documentary about scandalous sanitary conditions at Foo sausage factory ;)

Re: Trunk Based Development

#42

Post by ahartmetz »

locknitpicker wrote: post #36
ahartmetz wrote: post #21

Earlier quoted context omitted.

Why in the world would you do squash merges? ...except to clean up messy mini-branches written by total noobs. I don't do separate commits for funzies. If you want separate commits for ease of review, why not for later reading of the code. Assumption: above mentioned total noobs don't use git rebase -i or equivalent, everyone else does

> Why in the world would you do squash merges? Why would you not want to squash merges? It's one of three options offered by GitHub in their PR merge buttons. They create a linear commit history, which is what you want when you have to audit changes. > except to clean up messy mini-branches written by total noobs. Nonsense. You get a messed up commit history as easily as when you create a PR in GitHub, and after team…

Rebasing fixes all of the problems for which you present squash merges as the only solution.

Re: Trunk Based Development

#43

Post by homebrewer »

lloeki wrote: post #27
aidos wrote: post #22

Earlier quoted context omitted.

It’s pretty hard to keep the commits in a working branch in a good legible state - certainly it takes work to do it. In 25 years of professional development I’ve never really had a situation where the commits on a branch would have helped me understand what was going on a year ago when the work was done. That includes pretty big bits of project work. I’d much rather have a trunk with commits at the granularity of fea…

In 25 years of professional development I have several counter examples where some bit was either a trivial git revert of a single commit - among multiple ones in a branch - away, or an absolute pain because the squash-merge commit had flattened too many concerns together, concerns that were perfectly split in the topic branch but that branch was long gone by virtue of being auto-deleted on PR merge. Coincidentally,…

I take it you haven't had the pleasure of working with your average ("dark matter" as they're called here) developers. I wouldn't call myself an "advocate" of squashes, but it's often the only practical way of keeping git history somewhat usable when working with people who refuse to learn their VCS properly.

I chunk my changes into tiny commits ("linter"/"tmp"/"wip"), but then rebase aggressively, turning it into a set of logical changes with well-formed commit messages. git bisect/revert work great with history written in this way even years layer.

But: most of the people I've been interacting with also produce lots of "wip"/"tmp", but then skip the rebase. I can only offer my help with learning git rebase for so long before it starts taking too much time from the actual work. So squash it is: at least it produces coherent history without adding thousands of commits into `--ignore-revs-file`.

Re: Trunk Based Development

#44

Post by ahartmetz »

xen0 wrote: post #38
ahartmetz wrote: post #21

Earlier quoted context omitted.

Why in the world would you do squash merges? ...except to clean up messy mini-branches written by total noobs. I don't do separate commits for funzies. If you want separate commits for ease of review, why not for later reading of the code. Assumption: above mentioned total noobs don't use git rebase -i or equivalent, everyone else does

I want every commit to represent a buildable state in which I have confidence automated tests pass. Bisecting is made unnecessarily difficult otherwise, and it's nice to be able checkout any commit and just build something for testing. This constraint is usually enforced by code review. On Github, the unit of code review is the PR. Therefore, I prefer squashing.

>On Github, the unit of code review is the PR.

It is, and that is some bullshit. The only sensible way to work with that is to break up larger features into several PRs - which is often positive anyway, but sometimes it doesn't fit the nature of the change.

Re: Trunk Based Development

#45

Post by ahartmetz »

skydhash wrote: post #35
lloeki wrote: post #27

Earlier quoted context omitted.

In 25 years of professional development I have several counter examples where some bit was either a trivial git revert of a single commit - among multiple ones in a branch - away, or an absolute pain because the squash-merge commit had flattened too many concerns together, concerns that were perfectly split in the topic branch but that branch was long gone by virtue of being auto-deleted on PR merge. Coincidentally,…

If you work with a ticket system, squash-merge gives you the same granularity, where a commit would refer to a single ticket. A ticket should be atomic describing a single change request. PR in this case are the working room. It can be as messy or as clean as you want. But the goal is to produce a patch that introduces one change. Because if you would rebase -i at the end, you would have a single commit too in the PR…

No, you wouldn't. git rebase -i is to remove noise, which is about merging commits that, well, make more sense together than apart. Which is mostly about summarizing trivialities (e.g. several typo fixes) and squashing fixups into commits that introduced a problem in the same branch.

A typical bugfix branch might look like this after rebase -i:

Move property to a more appropriate place

Improve documentation of feature Foo

Fix accidental O(n^2) in feature Bar

Fix interaction of Foo with Bar

Re: Trunk Based Development

#47

Post by amabito »

swiftcoder wrote: post #5

stacked PRs. stacked PRs! Seriously wish the stacked PR workflow would gain more traction outside of FAANG. Apart from the (somewhat pricey) Graphite offering, there's no standard UI for managing stacked PRs in the wild.

The tooling gap exists partly because git's data model has no native concept of "this branch's upstream is another feature branch" — each PR is independent from the forge's perspective, so rebasing one layer in the stack requires manually re-targeting every PR below it. FAANG-internal tools solve this by storing the stack relationship in a metadata layer outside git itself, then regenerating the PR graph after each rebase. Without that layer, the bookkeeping falls on the developer, which is why most teams abandon the workflow after two or three levels deep regardless of how disciplined they are.

Re: Trunk Based Development

#48

Post by skydhash »

ahartmetz wrote: post #45
skydhash wrote: post #35

Earlier quoted context omitted.

If you work with a ticket system, squash-merge gives you the same granularity, where a commit would refer to a single ticket. A ticket should be atomic describing a single change request. PR in this case are the working room. It can be as messy or as clean as you want. But the goal is to produce a patch that introduces one change. Because if you would rebase -i at the end, you would have a single commit too in the PR…

No, you wouldn't. git rebase -i is to remove noise, which is about merging commits that, well, make more sense together than apart. Which is mostly about summarizing trivialities (e.g. several typo fixes) and squashing fixups into commits that introduced a problem in the same branch. A typical bugfix branch might look like this after rebase -i: Move property to a more appropriate place Improve documentation of featur…

Those looks more like noise to me. A squashed merge (or a final squash before PR) would be:

  TN 43 - Fix mismatched interface between Foo and Bar

  We've moved the X property to a more appropriate place and
  improved the documentation for Feature Foo. We've also found and fix
  an O(n^2) implementation in feature Bar.
The the ticket TN-43 will have all the details that have lead to the PR being made: Bug reports, investigations, alternative solutions,...

The commit message is what's more important. I don't think I've ever needed what is in a merged branch. But I've always wanted the commit at one point to have tests passing and a good description of the patch. And all the talk in the engineering team are always about ticket. It does makes sense to align those.

Re: Trunk Based Development

#49

Post by skydhash »

homebrewer wrote: post #43
lloeki wrote: post #27

Earlier quoted context omitted.

In 25 years of professional development I have several counter examples where some bit was either a trivial git revert of a single commit - among multiple ones in a branch - away, or an absolute pain because the squash-merge commit had flattened too many concerns together, concerns that were perfectly split in the topic branch but that branch was long gone by virtue of being auto-deleted on PR merge. Coincidentally,…

I take it you haven't had the pleasure of working with your average ("dark matter" as they're called here) developers. I wouldn't call myself an "advocate" of squashes, but it's often the only practical way of keeping git history somewhat usable when working with people who refuse to learn their VCS properly. I chunk my changes into tiny commits ("linter"/"tmp"/"wip"), but then rebase aggressively, turning it into a…

And sometimes, a patch is just that big. especially in UI works where a single change can cascade down to multiple layers.

> I chunk my changes into tiny commits ("linter"/"tmp"/"wip"), but then rebase aggressively, turning it into a set of logical changes with well-formed commit messages. git bisect/revert work great with history written in this way even years layer.

In a PR based workflow, it has become easier to have the PR be a logical unit than to `rebase -i` all the time on my end.

Re: Trunk Based Development

#50

Post by sodapopcan »

skydhash wrote: post #48
ahartmetz wrote: post #45

Earlier quoted context omitted.

No, you wouldn't. git rebase -i is to remove noise, which is about merging commits that, well, make more sense together than apart. Which is mostly about summarizing trivialities (e.g. several typo fixes) and squashing fixups into commits that introduced a problem in the same branch. A typical bugfix branch might look like this after rebase -i: Move property to a more appropriate place Improve documentation of featur…

Those looks more like noise to me. A squashed merge (or a final squash before PR) would be: TN 43 - Fix mismatched interface between Foo and Bar We've moved the X property to a more appropriate place and improved the documentation for Feature Foo. We've also found and fix an O(n^2) implementation in feature Bar. The the ticket TN-43 will have all the details that have lead to the PR being made: Bug reports, investiga…

They aren't noise at all and have found them useful a bunch in the past when I worked at a place that didn't squash. Commits at this level act as immutable comments that don't get out of date. Provided you do --no-fast-forward merges, the merge commit is the feature commit and you can get the "clean" feature history with `git log --merges --first-parent`. Best of both worlds! Being able to `git blame` and get a granular message about why something was done can be really handy, especially when looking unfamiliar code.
Post reply on HN