Programming

21961 readers

103 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 2 days ago* (last edited 2 days ago) by HaraldvonBlauzahn@feddit.org to c/programming@programming.dev

14 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

[–] HaraldvonBlauzahn@feddit.org 6 points 2 days ago* (last edited 2 days ago) (3 children)

Have you ever seen or created something like this?

This might explain why it might be useful to re-write history at all, and why tools like jujutsu or gerrit are interesting, in specific contexts.

[–] Kissaki@programming.dev 1 points 2 days ago (1 children)

While exploring solutions, I use f or ffto mean "follow-up/to-squash" and a to mean logically separate. Sometimes other (additional) short abbreviations to know where to move, squash, and edit the changes to.

Other than maybe initial development until the first stable/usable version, these never persist, though. And even then, only if it's not a collaborative project. If it is shared or collaborative, "Iterate on x" is preferable as a non-descriptive title.

I guess my commit descriptions get better with project lifetime, not worse.

[–] Fred@programming.dev 3 points 2 days ago

While exploring solutions, I use f or ffto mean “follow-up/to-squash” and a to mean logically separate. Sometimes other (additional) short abbreviations to know where to move, squash, and edit the changes to.

I recently discovered git commit --fixup=abcd1234: it will make a new commit with a message of fixup! <message from abcd1234>. (It's the only special thing that flag does: a specially formatted commit message, which you can craft yourself if you remember the spelling of the fixup! marker.)

When you later rebase, git rebase --interactive --autosquash will automatically mark that commit to be a fixup of abcd1234.

magit for emacs has shortcut for creating a fixup commit selecting the previous commit, I'm sure other interfaces do too.

I guess my commit descriptions get better with project lifetime

I've found that too, which I think is because as the project matures, you're more likely to make fixes or contained features, as opposed to regular "change everything" as you explore the design in a young project.

load more comments (1 replies)