Comment by IanCal | Hacker News Reader

Comment by IanCal | Hacker News Reader

First off, thanks for building and releasing something.

I think I might be missing something though, I have never understood why having a clean history (when the real history isn't clean) is important.

If you've got huge branches with scary merges, isn't the problem that you have huge long lived branches? Why does it matter that my graph shows when I actually did merge things?

I usually hear a git bisect argument around this, but are there good examples where it becomes a problem? Bisect lets you specify when to skip a commit, so you can be as selective as you want with it.

Lots of people complain about problems rebasing, and I've repeatedly seen issues where people mess up and that causes more pain when just merging seems to work perfectly fine. It seems like a lot of work, effort and time to avoid potential issues later (and even then I'm not sure what those issues are).

This isn't rhetorical, given so many people have strong opinions on this I assume I'm missing something important.

It's much easier to review a feature branch that has a clean history. Especially if it's remotely complex. If every commit is self-contained and each adds only one logical feature dependency, then every commit can be reviewed individually for correctness and unintended side-effects, rather than the entire complex diff as a whole.

If you really care about this, rebasing is a shitty solution. Patch queues like mercurial's make it much easier to logically decompose a feature into a series of patches and shuffle code between the commits until they all settle nicely.

I say this having gone from a mercurial user that produced pristine commit histories to a git user that makes dirty, nasty histories.

Why are you making dirty, nasty histories? The git users on kernel.org sure don't, and I bet they have more complex branches in flight than you do...?

But how often that ideal is true? It assumes that developers don't make mistakes in any of the commits, or never add "temporary" code which is removed in later commits of the feature branch. This is the reason that I tend to review a single diff, so that I don't have to browse through numerous commits and check if some line of code in a commit ends up being in the final merge diff.

No, it assumes that developers clean up their branch history as necessary before submitting it for code review.

That seems like a lot of work just to make code review easier. Of course, you can clean up the branch history by squashing commits, but that's the same as reviewing the complete merge diff..

Not just code review. It also significantly helps reviewing history later, which is done for any number of reasons, including tracking down where bugs were introduced, understanding the reason for a given change, etc.

I've worked in projects that always keep a clean history. And I've worked in projects where developers don't bother cleaning up history before pushing. And in every non-trivial project that follows the latter I've always hit cases where I try to track down something through the history only to find that the history doesn't capture the meaning of the code. This is not just bad merge behavior, but also things like lumping unrelated changes together into a single commit.

Even something just as simple as reading recent history to keep up with the changes being made to the codebase is significantly simpler if developers are diligent about keeping a clean history. For example, the Rust project has a lot of activity, but also has a strict code review policy that means that nearly all commits are done with a clean history (very occasionally, long-lived branches are allowed through that have control merges, but those are rare). And as a result, even though I no longer have the time to actively contribute, I've still managed to keep with every non-trivial change made to Rust merely by periodically reading through the history since my last pull. I can't imagine trying to do that if the history weren't clean.

Arguably the only reason it could be a lot of work is when the submitter doesn't really understand the code that multiple mixed up and muddled commits have resulted in. By giving your reviewer a mess, you're only asking for the reviewer to make sense of it instead of doing it yourself.

Instead, breaking up the feature into logical pieces allows you to documented every step properly in a separate commit message.

If you properly understand what you're submitting for review, then it isn't really much work at all. It's even easier if, during original development, you commit often. But you can always split commits up during rebasing, too.

Supposed there is an undesirable behavior caused by some subtle interaction of features coming from 2 branches.

With a normal merge, git bisect will likely point to the merge commit as the first commit that introduced the behavior, which was the first time these 2 branches ever interacted. This means resolving inconsistencies after the fact, somewhat similar to "eventual consistency". It is more coarse-grained, can be harder to reason about, but may scale better (no serialization).

With a rebase, git bisect will point to one of the rebased commits, each of which already interacted with the branch coming before. Rebasing is sort of similar to the situation where DB client retries a transaction because the DB doesn't know how to serialize 2 transactions. It is more fine-grained, can be easier to reason about, but may have problems scaling, and may sometimes be tedious.

For me, git bisect really does become much more interesting to use when feature branches are rebased to get a clean history. Just reading the history becomes easier, since each feature branch has a self-contained part of the ordered history.

In addition, it is also useful when merging a feature branch turns out to be a problem later on. Reverting a rebased merged feature branch is very easy, without having to think about if there any issues with mid-branch merges and so on.

Reply on news.ycombinator.com