Hacker News Reader

Comment by wdfx | Hacker News Reader

IMO the pursuit of, or even a concept of 'clean history' is a fallacy and waste of time. It is a level of obsession which I think is just not worth it. Furthermore, a commit log is not the same thing as release notes. More often than not you need release notes for a product to be constructed in a user centric manner, describing features or changes which affect them - and that actually comes from the original requirements lists and not the minute implementation details.

IMO don't rebase, don't worry about 'clean' history. Obsessing over those is time consuming and risky. Just do your work and move on. Let your manager/lead deal with the external world.

View on HN

> Obsessing over those is time consuming and risky

That's interesting, because to me, it's slopy. If someone doesn't worry about git history, it typically means they don't do pull requests, and that typically, they don't understand know how git works (i.e. how to leverage the features of git).

For me, worrying about history literally takes no extra time. I honestly don't understand the argument.

Pull requests is not the only way to collaborate in a team. git also works with other tools for review and merging can be done by other means.

Hi, Pascal here. The author.

Just to clarify this: The aim of rebasing is not a clean commit history. It enables you to make one in case you've been creating lots of work-in-progress commits with no semantic meaning, which makes it harder to work with it.

However, even if you stick to that, it's not like rebasing isn't of value anymore. You might still be interesting in squashing your commits or splitting them up or simply rebase on branch on top of another for various reason.

That said, I'd recommend to not advocate not to rebase if it's based on the assumption that it's only useful for clean commit histories.

> IMO the pursuit of, or even a concept of 'clean history' is a fallacy and waste of time. It is a level of obsession which I think is just not worth it.

While I do obsess over a git clean history (at least in my personal projects), I still mostly agree. Doing rebase instead of merge to have a cleaner history (as in git log) might not be worth it (git log --no-merges will return a similar image). But there's one feature I use constantly that relies on not having any useless commits on it: git blame. Whenever I'm asking myself why a changes was made (at least weekly), I'm looking for the commit that introduced the change. Things like "fix typo" or "add missing files" don't help. Hence, I am doing a lot of amends and interactive rebases to combine changes that belong to each other. It may take 2 more minutes, but it will make my (and my collegues') life easier in the future.

Sure that's all fair enough. I'm not advocating being sloppy either - just be pragmatic about the effort/reward.

If you follow a PR heavy or PR only methodology heavy on meaningful merges with good descriptions, `git log --first-parent` can be more useful than `git log --no-merges`. It's more condensed and focused on high level features instead of the smaller baby steps that build up the high level. `git blame` also accepts `--first-parent`.

Reply on news.ycombinator.com