Hacker News Reader

Comment by daemin | Hacker News Reader

You can rewrite the git history when you squash commits for example.

One case I've heard is that some people no longer have their names on git commits they made to various Google open source projects because their commit went inside, where it was rebased, merged, integrated, squashed, and then what the public sees is a single git commit by a Google insider that is the result of thousands of individual commits.

View on HN

This is a beautiful example of the general case «why don’t you just use X tool that was designed for this?» but can’t because someone made a decision that makes X tool unusable.

Workflows are full of trade offs. Different people & teams value different features in different ways. It’s what makes software development such a vibrant ecosystem.

I don't understand the need to rewrite history. This is a good example against that practice.

Because it becomes more compact. Most of the time git commits are things that don’t make sense to have at a more macro level. Squashing into a single commit that represents a coherent improvement, particularly for large projects, is the best way to read its history.

I prefer a small branch with many individual commits (cleaned from fixups or not) and a merge with main branch which adds the whole feature. Then you can have two levels of reading.

Doesn't this still put all the commits on the main branch?

No you commit in feature branches then merge to main branch.

Do you then keep the branch around forever?

The branch history is preserved in the commit graph of the main branch, so you don't need to keep the feature branch.

You can keep the branch commits for detailed history, and look only at merge commits the when you don't need details:

     git log --first-parent -m

This will show a linear history of merges, treating the merged code as being added in the merge commit. You can add -p to see the diffs.

But then does it matter at all that the date of the comment was the day where you committed the todo, or two days after when you squashed it ?

At least these days co-authorship can be recorded in the commits.

That’s just conflating GitHub support of these tags with git. Similar "Signed-off-by" tags are in use by Linux kernel pretty much since forever.

But then cherrypicking doesn;t preserve commit metadata, does it?

Reply on news.ycombinator.com