4 ms·

Reading "rewrite history" sets off so many red flags for me I struggle to take this seriously. What are you trying to do? Are you embarrassed that you arrived

by lijok 2y ago

Reading "rewrite history" sets off so many red flags for me I struggle to take this seriously. What are you trying to do? Are you embarrassed that you arrived at an end goal via a suboptimal sequence of steps, and are trying to present it in a way that conceals that fact? Is the auditor at the door? What's the end goal here?

PhilipRoman 2y ago
Maintaining forks/extensions of opensource upstream projects is a pretty good use for it.
- lijok 2y ago
  Interesting, could you elaborate? I'm unfamiliar with that usecase
  - PhilipRoman 2y ago
    I've maintained an internal fork of "hostapd" tool. We needed a bunch of additional WiFi features and in some places different behavior due to hardware architecture. Initially it had a normal Git history, which made it a pain to update (as a consequence, this was not done at all except for cherry picking security fixes). Merging any significant upstream changes was impossible and all clients would be limited to using our exact hostapd codebase. The solution was to identify our changes, split them into meaningful feature commits, keeping upstream and our code as separate as possible. After this change, updating the upstream by ~2 years took about 4 days. Most importantly, the history is kept clean by marking what commits go where, and doing cleanup every couple of months (no code diffs are allowed at that moment, only git history may be rewritten). The new history can also be exported as patches, so that any client can (selectively) apply them on top of their own hostapd.
falcojr 2y ago
Rewriting history on main is bad. Rewriting history everywhere else is completely normal and should be encouraged. I don't want your "oops typo LOL" commits in main. I don't want a history that looks like "refactor stuff"->"new feature"->"1 line change to that thing I refactored". That one line change should go into the old commit. Fix all of that before you merge to main.
corytheboyd 2y ago
They’re just talking about interactive rebase, why is that a red flag? At least I work this way, where I make “not so good” commits sometimes, when I know I don’t have a good atomic commit, but want to create a checkin because “something works now”. Then I later use interactive rebase to make the actual atomic commits, with appropriate messages and bodies. Am I was supposed to be perfect on the first pass?
igrunert 2y ago
There are a handful of git features which work significantly better with a clean history on main. If `git blame` points at a well crafted commit, it can help bring additional context to the line in question. In addition `git log -S<string>` can be used to find when code was introduced. Both of these features aren't very useful when they point at a "wip" or similar commit message. By all means push lots of little commits to your branch while you're figuring stuff out, but squash and rewrite history into logical commits (usually just one) before landing the change on main.
- JelteF 2y ago
  I learned about the --first-parent flag of git blame recently. It allows git blame to work well in repos that use merge commits.
  - 3np 2y ago
    There is also -r, which leaves merge commits and lets you move them around.
0x696C6961 2y ago
There's nothing I love more than git blaming and searching through 100s of "oops" and "edit" commits /s

by lijok 2y ago

PhilipRoman 2y ago

Maintaining forks/extensions of opensource upstream projects is a pretty good use for it.

lijok 2y ago
Interesting, could you elaborate? I'm unfamiliar with that usecase
- PhilipRoman 2y ago
  I've maintained an internal fork of "hostapd" tool. We needed a bunch of additional WiFi features and in some places different behavior due to hardware architecture. Initially it had a normal Git history, which made it a pain to update (as a consequence, this was not done at all except for cherry picking security fixes). Merging any significant upstream changes was impossible and all clients would be limited to using our exact hostapd codebase. The solution was to identify our changes, split them into meaningful feature commits, keeping upstream and our code as separate as possible. After this change, updating the upstream by ~2 years took about 4 days. Most importantly, the history is kept clean by marking what commits go where, and doing cleanup every couple of months (no code diffs are allowed at that moment, only git history may be rewritten). The new history can also be exported as patches, so that any client can (selectively) apply them on top of their own hostapd.

falcojr 2y ago

Rewriting history on main is bad. Rewriting history everywhere else is completely normal and should be encouraged. I don't want your "oops typo LOL" commits in main. I don't want a history that looks like "refactor stuff"->"new feature"->"1 line change to that thing I refactored". That one line change should go into the old commit. Fix all of that before you merge to main.

corytheboyd 2y ago

They’re just talking about interactive rebase, why is that a red flag? At least I work this way, where I make “not so good” commits sometimes, when I know I don’t have a good atomic commit, but want to create a checkin because “something works now”. Then I later use interactive rebase to make the actual atomic commits, with appropriate messages and bodies. Am I was supposed to be perfect on the first pass?

igrunert 2y ago

There are a handful of git features which work significantly better with a clean history on main. If `git blame` points at a well crafted commit, it can help bring additional context to the line in question. In addition `git log -S<string>` can be used to find when code was introduced. Both of these features aren't very useful when they point at a "wip" or similar commit message. By all means push lots of little commits to your branch while you're figuring stuff out, but squash and rewrite history into logical commits (usually just one) before landing the change on main.

JelteF 2y ago
I learned about the --first-parent flag of git blame recently. It allows git blame to work well in repos that use merge commits.
- 3np 2y ago
  There is also -r, which leaves merge commits and lets you move them around.

0x696C6961 2y ago

There's nothing I love more than git blaming and searching through 100s of "oops" and "edit" commits /s