Hacker News Reader

Comment by ohwellhere | Hacker News Reader

The way I phrase and teach what I consider to be the important rule of git is:

> Don't rewrite history on shared branches with proper communication.

I don't teach "never", I don't teach that `main` is special, I don't teach that force pushing is forbidden, because I don't believe in those things.

I highly prefer a rebase-heavy workflow. In addition to not "cluttering" the history, it's an invaluable tool to keep commits focused on "the right level" of atomic changes.

View on HN

You can simply pass flags to “git log” to hide merge commits, without needing to rewrite history to “destroy” that information. While they are often noisy, sometimes they can be useful. I usually prefer to hide information rather than destroy it.

I read this justification in nearly every thread that pops up git rebase. I feel like a full because I cannot think of a real world example when this information crosses from signal to noise. Generally, branches that are not ready to merge tend to have enormous amounts of noise commits. Is there a blog post or some concrete examples I could work through that illustrate these benefits? I feel like workflows dramatically different from mine are likely the source of my struggle.

It's a log of what happened in dev and supports reconstructing history to understand why something worked or didn't in retrospect. "It work when we tried it" "oh this dependency was updated in this merge commit that could have changed the behaviour"

I am not sure how this is unique to a merge commit. The commit with the dependency change still exists in the main branch. The commit should never have gotten into main branch of it failed tests. If I take a positive action to rebase, I am accepting my fate from master anyway. If I merge into my working branch instead of rebase, that historical context issue only useful for that moment in time of reconstructing history and is not useful anymore. Once a branch goes into master, I want commits to main to have a 1:1 ratio of committed code for a task to positive action taken by a human.

It's not unique to a merge commit of course, but a point in favour of preserving history.

I assume that “with” is meant to be “without”?

It’s annoying when someone force pushes to a branch that you just reviewed, but you can no longer see the history so you have to scan through the whole PR you already reviewed looking for the change. Please just commit the fix, let me see it, then squash it.

You can just diff the previous head with the new one. In GitLab, it's simply a matter of clicking "Compare with previous version". Locally, it's `git diff branch@{1}..branch`.

It's only becoming tricky if the MR has been rebased onto a different base in the process, but it's not very hard to deal with that too if needed (just annoying).

Actually, it's not that annoying at all - TIL about `git range-diff`.

Unfortunately I haven't seen a git forge that will let you do "autosquash on merge" so I could just push up fixup commits as part of an merge request.

GitHub: https://docs.github.com/en/repositories/configuring-branches...

That always squashes the whole PR into a single commit, making it not very useful in practice. Git's autosquashing is much more powerful than that.

Reply on news.ycombinator.com