2 ms·

I really hate rebases. Maybe, with a little compression, we have enough disk space to simply do both. After squashing and rebasing, some normally-hidden data

I really hate rebases. Maybe, with a little compression, we have enough disk space to simply do both. After squashing and rebasing, some normally-hidden data in the commit lets a client resurrect the original, highly-detailed commit graph including every "uh forgot to commit on Friday afternoon, dunno what this was but it's important" commit. (Of course you can always redact sensitive data, as long as you control and trust every hard disk the data is on)

pjc50 3y ago
> some normally-hidden data in the commit lets a client resurrect the original, highly-detailed commit graph including every "uh forgot to commit on Friday afternoon, dunno what this was but it's important Is that supposed to be a good or even useful thing?
- kbolino 3y ago
  There are in-band and out-of-band ways of communicating information that matters to your collaborators (including future-you) but not to the compiler. Commit messages (out-of-band) tie this information to the specific time when the change was made. They also don't clutter the code up. Comments (in-band) tie this information to the specific place where the change was made. If overused, they make the code harder to read. Commits can get lost in the noise, though blame and bisect can help find them. Comments can get stale and cause more confusion than assistance. Honestly, if we spent more time reviewing and revising each other's code than just writing it, then comments (combined with refactoring for readability) would probably be the better solution. But that would slow down development. If you're going fast or lean, then relying on commit messages is better than nothing at all or fired-and-forgotten comments.
- 01HNNWZ0MV43FF 3y ago
  It's one of those things I rarely need, but really need when I do need it. Commit numbers are an API and it's frustrating when I write something like "Fixed in commit xyz" or "Broken in commit xyz" or "Tested manually in xyz" and then after a rebase (Not a private rebase I asked for, but part of the CI routine), my comment makes no sense and Github says "We can't find that commit". You can paste it in manually but the context is lost, it's not in `git log --graph` anymore.
kbolino 3y ago
Rebasing can do a lot more things than just squashing. I personally hate seeing dozens of semantically meaningless pull-merge commits ("merged branch main into main"). I don't care when you pulled or what effect it had on your local history. When you push, push a clean linear history starting from where other people left off. If you spend too much time working independently on a "branch" (your version of main diverging from everyone else's version of main), then you're not collaborating and you're not continuously integrating your work. I do like the idea of being able to compress the history you're squashing, though. There can be a lot of trivial commits, but depending on workflow, squash-merge can hide subtle things like the reason you made a very important one line change.

pjc50 3y ago

> some normally-hidden data in the commit lets a client resurrect the original, highly-detailed commit graph including every "uh forgot to commit on Friday afternoon, dunno what this was but it's important Is that supposed to be a good or even useful thing?

kbolino 3y ago
There are in-band and out-of-band ways of communicating information that matters to your collaborators (including future-you) but not to the compiler. Commit messages (out-of-band) tie this information to the specific time when the change was made. They also don't clutter the code up. Comments (in-band) tie this information to the specific place where the change was made. If overused, they make the code harder to read. Commits can get lost in the noise, though blame and bisect can help find them. Comments can get stale and cause more confusion than assistance. Honestly, if we spent more time reviewing and revising each other's code than just writing it, then comments (combined with refactoring for readability) would probably be the better solution. But that would slow down development. If you're going fast or lean, then relying on commit messages is better than nothing at all or fired-and-forgotten comments.
01HNNWZ0MV43FF 3y ago
It's one of those things I rarely need, but really need when I do need it. Commit numbers are an API and it's frustrating when I write something like "Fixed in commit xyz" or "Broken in commit xyz" or "Tested manually in xyz" and then after a rebase (Not a private rebase I asked for, but part of the CI routine), my comment makes no sense and Github says "We can't find that commit". You can paste it in manually but the context is lost, it's not in `git log --graph` anymore.

kbolino 3y ago

Rebasing can do a lot more things than just squashing. I personally hate seeing dozens of semantically meaningless pull-merge commits ("merged branch main into main"). I don't care when you pulled or what effect it had on your local history. When you push, push a clean linear history starting from where other people left off. If you spend too much time working independently on a "branch" (your version of main diverging from everyone else's version of main), then you're not collaborating and you're not continuously integrating your work. I do like the idea of being able to compress the history you're squashing, though. There can be a lot of trivial commits, but depending on workflow, squash-merge can hide subtle things like the reason you made a very important one line change.