8 ms·

It's ironic that the "history is sacred" crowd contains the people least likely to actually look at and use the git history to aid their contextual understandin

It's ironic that the "history is sacred" crowd contains the people least likely to actually look at and use the git history to aid their contextual understanding of the codebase. Why do I say that? Well, because once you've come across a useless typo commit for the 12th time, you start to very quickly see how such commits needlessly bloat the history and make it far harder to understand (and make things like git blame much more unwieldy), while not actually offering any benefit. It doesn't matter to me at all 3 months later to know that you initially had a typo in your first commit and then fixed it the subsequent commit. That should just be a single commit. There are some very rare edge cases where having the whole messy history can offer some insight of how a certain mistake ended up being made, but IMO in 999/1000 cases that's not the case.

Arelius 4y ago
Squashing and rebasing don’t fix the shitty commit message problem. Discipline and good teamwork do. All to often in rebase+squash heavy repos I start going through the history and find the mega-commit that introduced a change and gain zero insight. In comparison, merge heavy repos have a lot of merge this, or fix this typo commits, that are fairly easy to skip right over when not pertaining to your actual change, but prove invaluable when the problem was introduced by some weird bad conflict resolution including a typo, or countless other problems where just all context is otherwise lost. I think it’s unfair to characterize one group as not using the history, but instead represent differences in how groups use them. As an archaeologist vs daily change log perhaps is a better characterization?
GuB-42 4y ago
That's why when you use a "history is sacred" approach, you typically have several branches and use merge commits, not rebase. When you look at the master branches you will mostly see merge commits, all the mess will be on the side, for example in feature branches. Merge commits can be clean, and when you are blaming, you will see the merge commit, not the dozen of typo commits. If you do "git log --first-parent" you will not even see the messy commits, but they will be there if you need them.

Arelius 4y ago

Squashing and rebasing don’t fix the shitty commit message problem. Discipline and good teamwork do. All to often in rebase+squash heavy repos I start going through the history and find the mega-commit that introduced a change and gain zero insight. In comparison, merge heavy repos have a lot of merge this, or fix this typo commits, that are fairly easy to skip right over when not pertaining to your actual change, but prove invaluable when the problem was introduced by some weird bad conflict resolution including a typo, or countless other problems where just all context is otherwise lost. I think it’s unfair to characterize one group as not using the history, but instead represent differences in how groups use them. As an archaeologist vs daily change log perhaps is a better characterization?

GuB-42 4y ago

That's why when you use a "history is sacred" approach, you typically have several branches and use merge commits, not rebase. When you look at the master branches you will mostly see merge commits, all the mess will be on the side, for example in feature branches. Merge commits can be clean, and when you are blaming, you will see the merge commit, not the dozen of typo commits. If you do "git log --first-parent" you will not even see the messy commits, but they will be there if you need them.