Re: [git pull] drm-next
www.mail-archive.com

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.

  • Fred@programming.dev
    0·
    13 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.