News for hackers. Stuff that matters.
Re:Git-absorb: Git commit –fixup, but automatic by IshKebab on Thursday September 26, 2024 @04:40AM (#41656003)
The point of history is so that other people (or your future self) can look back at the history of the code and understand how it changed and why changes were made.

There's zero value in retaining mistakes that were never merged into `master`. In fact there is negative value because it makes the history harder to follow.

For example would you rather see "review fixes" in Git blame, or the actual useful commit message?

You can argue that you can't be bothered to make your history nice; fine. But you can't say it's wrong to do that.

(Personally I think you should squash commits for a MR; if it's too big to review as one commit it's too big for one MR - except for branches that multiple people have worked on over an extended period.)

Re:Git-absorb: Git commit –fixup, but automatic by Terr_ on Thursday September 26, 2024 @06:20AM (#41656648)
> There's zero value in retaining mistakes that were never merged into `master`.

Not to be too pedantic about this, it sounds like you mean flawed commits that were merged into master, but never had a chance to be the HEAD of master? (In other words, they always arrived along with a fix-commit too, so that nobody checking out code could've hit the bug.)

> In fact there is negative value because it makes the history harder to follow.

It also hampers your ability to use tools like git-bisect to detect when behavior changed, especially if some of the bad commits won't compile or pass unit tests.

Re:Git-absorb: Git commit –fixup, but automatic by IshKebab on Thursday September 26, 2024 @04:41PM (#41663120)
> flawed commits that were merged into master, but never had a chance to be the HEAD of master

Yeah exactly.