3 ms·

I see lots of comments here on how important it is to preserve "history of what really happened", arguing that cleaning up the history "is a lie the same way th

by tuxie_ 5y ago

I see lots of comments here on how important it is to preserve "history of what really happened", arguing that cleaning up the history "is a lie the same way that people who wear makeup are 'lying'" and that "someone might learn something from it". I feel that it's quite over the top. Nobody goes to the commit history to "learn programming" (or at least you should not) and if you did, it would be so confusing to see things added in a way and changed back 2 commits later because it didn't work. The code is just half the story, it needs context, it doesn't represent the train of thought behind the changes, that's only in your head. If you want to document what didn't work write a document where you explain the different approaches you took, why they didn't work and what you did at the end. That really is super useful. Just keep the history clean, if you ever need to revert a change you will be grateful you didn't add many changes to 1 commit or didn't change the same code in 5 different commits throughout the PR. Keep the code working at each commit, if you ever need to `git bisect` you will be grateful you did.

bad_username 5y ago
The most important benefit of preserving the history is being able to go to an exact state of the program in the past. Pinpointing the commit that introduced a regression is often by far the quickest method to localize the problem. And it is impossible when the history is rewritten, and consists of snapshots that were never even ran. This benefit is much more important than having a visually pleasing history. And you can always get a visually pleasing history by adding a few flags to git log.
- TomSwirly 5y ago
  > The most important benefit of preserving the history is being able to go to an exact state of the program in the past. No one's talking about ever getting rid of any commit ID that got checked into `main` or `master`. We're talking about getting rid of commit IDs that only ever existed on one machine and only during development. From my reflog, I see this commit ID: `21b9f2e HEAD@{28}: commit: Fix and instrument nstray URL problem` No one needs to know about my typo - ever.

by tuxie_ 5y ago

bad_username 5y ago

The most important benefit of preserving the history is being able to go to an exact state of the program in the past. Pinpointing the commit that introduced a regression is often by far the quickest method to localize the problem. And it is impossible when the history is rewritten, and consists of snapshots that were never even ran. This benefit is much more important than having a visually pleasing history. And you can always get a visually pleasing history by adding a few flags to git log.

TomSwirly 5y ago
> The most important benefit of preserving the history is being able to go to an exact state of the program in the past. No one's talking about ever getting rid of any commit ID that got checked into `main` or `master`. We're talking about getting rid of commit IDs that only ever existed on one machine and only during development. From my reflog, I see this commit ID: `21b9f2e HEAD@{28}: commit: Fix and instrument nstray URL problem` No one needs to know about my typo - ever.