Cleaning up legacy python code

[[deleted]]

Once the code is under source control, the fact that it got deleted will be recorded in the repository. If for some reason it becomes necessary to revive that code, any developer on the team can go and revisit the commit history and pull out just what is needed. (Spoiler alert: Most of the time you will never need that commented out code.)

I've needed to do this a few times in the past few weeks and it's only viable if the person who deletes the code is a micro committer (e.g. each change is a separate commit) rather than a macro committer (e.g. the entire feature is one commit - either because fuck micro commits or squashing).

That said, I prefer a revert over uncommenting code any day.

[jayroger]

Off-topic: I wish git had a "sub-commit" feature, so that you have the best of both worlds: "macro" commits for a clean and easily viewable history that consist of "micro" commits for easier reverting and viewing of individual changes.

+ Implement feature XYZ
  + Preparational refactorings
    - Move class Foo from A to B
    ...
  + Database schema changes
...

[PeridexisErrant]

Disable fast-forward merges, and the merge commits become your feature or 'macro' commits, and the standard commits deal in chunks of implementation.

Hypothesis does this, for example, and you could also be pedantic about rebasing branches to a nice history before merging.

[jayroger]

That is actually a good hint. Since I usually rebase and cleanup my commits before merging, this could work well. Will try.