[Karunamon]

Could anyone who follows the "rebase all the merges" workflow detail why they choose to work that way? It seems to me that Git's strength is being able to time travel in your repo (especially with something like git-bisect, one of the few tools I'd call downright magical)

But if you're rebasing your commits, haven't you lost that? The concerns about a "clean commit graph" seem more aesthetic than functional.

[dimino]

I don't know about rebasing everything, but a commit is a changeset, and a changeset should always have a distinct and succinct purpose. There is no value added in having a single feature spread out over 5 commits.

When writing a feature, I use git to save my progress, and once I'm done, I would like to present the feature as a clear and complete changeset. A commit is me saying, "These are the changes I'd like to make to the codebase", and I feel that argument is easier to make when I present one thought, rather than the dozens of thoughts I had on the way.

If I were perfect, then I would commit in a way that was one cohesive thought, but I'm not. My commits are often, "Did the thing", then "redid the thing, with better testability", and "Re-redid the thing, fixing some fundamental bug in how I did the thing at first", etc.

[pawadu]

I really don't understand all the opposition ti this idea. This is exactly how git should be used, and it is how most successful large open source projects require you to work.

[steveklabnik]

  > more aesthetic than functional

It is easier to understand a cleaner history than a messy one.

  > haven't you lost that?

You've lost the ability to look through one kind of history, but not other ones. bisect still works if you've rebased.

[Karunamon]

Only easier to understand if the commit messages suck. If your commit messages are descriptive, and each commit is an atomic unit of work (in other words: following best practices) rebasing has thrown away history that you can never get back.

[steveklabnik]

Right, but often, that's not something that happens the first time around. The idea is that you rebase in order to get that kind of history 100% of the time.

You cannot get things perfect on the first try; this is part of the whole principle of code review. When my patch is perfect, except for that one little typo, what should be done? Is a history with two commits, one amazing, one saying "fix typo" with a one-character diff, or one commit that's perfect, an easier to understand history? What is actually lost by "throw[ing] away history that you can never get back"?

If it had been right in the first time, that history would have never even existed in the first place. So you end up with the exact same thing.

[Karunamon]

Did that typo fix introduce a bug? Maybe, maybe not, but many programmer hours have been wasted on incorrect single characters :)

If I were bisecting that repo, it's a lot easier and more useful to be able to point the finger at the one commit that actually changed the line, rather than having to parse the one monster squashed commit to find the one line that introduced the bug.

[steveklabnik]

I tend to write documentation, so no, not a bug. But even then, there's lots of small code-review things that aren't always about bugs; project style, naming conventions, etc.

Furthermore, if this is a PR that's open, then the "bug" would have never even landed. So looking through history to "find what caused the bug" would have not even been a thing.