87
Linus Torvalds on how and when to maintain a clean git history (2009) (www.mail-archive.com)
submitted 1 year ago* by to c/programming@programming.dev
18 comments fedilink hide all child comments
 

I want clean history, but that really means (a) clean and (b) history.

People can (and probably should) rebase their private trees (their own work). That's a cleanup. But never other peoples code. That's a "destroy history"

So the history part is fairly easy. There's only one major rule, and one minor clarification:

  • You must never EVER destroy other peoples history. You must not rebase commits other people did.

[...]

If you are working with git together with other people, it's worth a read.

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 1 year ago (1 child)

In non-minimal changesets, I would miss information/documentation about individual logical changes that make up the changeset.

It's usually possible to find this by navigating back to the PR which you can find referenced in the squash commit.

I guess this might be a larger problem for codebases not following a trunk-based approach, where PRs grows to very large sizes before going into the mainline branch.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 year ago

    Review iterations mean messy comits there though. And full documented history in Git seems preferable because you don't have to switch tools, and for persistence and robustness too, in case of repo/review platform changes (switching platforms etc).

  • permalink
  • fedilink
  • source
  • parent