Programming

24365 readers

539 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

UlrikHD@programming.dev

Linus Torvalds on how and when to maintain a clean git history (2009) (www.mail-archive.com)

submitted 5 months ago* (last edited 5 months ago) by HaraldvonBlauzahn@feddit.org 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

[–] GissaMittJobb@lemmy.ml 1 points 5 months ago (1 children)

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.

[–] Kissaki@programming.dev 1 points 5 months 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).