Hacker News Reader

Comment by nerdponx | Hacker News Reader

This is the big one for me. destroying Commit information just to keep the graph tidy is a bad idea in my opinion. It would be better if Git provided better tools for filtering the log, e.g. providing some mechanism to elide commits from parents of any merge commit other than the 1st.

View on HN

> destroying Commit information just to keep the graph tidy is a bad idea in my opinion

The commit information I see when telling teams to squash their branches on merge is not valuable.

* "fixing whitespace" * "incorporate review comments" * "fix broken test" * "fix other broken test"

(note, the broken tests were broken by the changes in the PR)

As soon as that PR is merged those commits are worthless. And there are branches with dozens of those "fixing X" commits that would otherwise pollute the commit graph.

> * "fixing whitespace" * "incorporate review comments" * "fix broken test" * "fix other broken test"

Things like this should not be standalone commits though, they should be incorporated into the previous branch by amending the original work. It takes some effort to have a useful git history, it does not just happen on its own.

Sounds like six vs half-dozen. Why does it matter if somebody amends vs squashes?

It does not matter if you have one commit. If your change is split into few commits for increased readability, in that case it does matter.

Do you really believe that if, for example, this change to btrfs filesystem https://lore.kernel.org/linux-btrfs/cover.1699470345.git.jos... would be squashed, nothing of value would be lost?

You can very easily rewrite your commit message on GitHub when squash merging. Since the organizations I work exclusively use squash merge, I often just update the commit to be more valuable, listing the important changes it contains. (And of course the PR in GitHub will contain the commit history of the branch that was squashed, as well as any discussion.)

IMO, this is a lot simpler and easier to do than rebasing your branch to have a flawless history.

I rather strongly disagree here.

Having whitespaces mucks up commit, causing you to lose focus of what's actually important.

I have `git blame` aliased to `git blame -w` which ignores whitespace-only changes.

You can also reblame when you come across this formatting commits.

Yep, intermediate commits on a branch tend to be completely worthless. I'd much rather have "git blame" point to the commit that contains the entire change together.

Agree strongly, it's nice in theory to view the intermediate commits but in practice have never needed to look at them

Those commits would be the bathwater one casts out alongside the useful commits in using squash merges.

If the useful commits are the "baby" in your bathwater analogy, all the useful information in those commits is in the squashed commit.

This assumes a branch being merged in represents one logical change (a feature/bugfix/etc) that is "right sized" to be represented by one commit.

Yes, but now it's mixed with the bathwater, and now morph into another metaphor as it become the needle in the haystack.

It's okay to have 'low information' commits one can easily ignore in your history, as long as the 'high information' ones stay readable and coherent.

You can usually see that in whatever tool youre using anyway. Blame -> find the PR -> see commit history.

You mean like for example `git log --first-parent`?

TIL, thank you! Now I know for a fact that squash-mergers have no excuse and can brandish the man page at them.

People in general just have no idea how much version control is able to do. For one example try running "git help log" and just tap page-down a few (dozen) times to get an idea what's in there.

For another example, you know how people hate aligning code vertically so much that linters don't allow it nowadays, the primary reason being that if you have to change the spacing then the diffs will identify far too many lines as having changed? Both git and svn have options to ignore whitespace changes:

  git diff -w
  svn diff -x -w

`--first-parent` also today works for blame and bisect.

Reply on news.ycombinator.com