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.

  • Kissaki@programming.devEnglish
    0·
    14 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.

    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
      0·
      14 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.