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.

  • HaraldvonBlauzahn@feddit.orgOP
    0·
    14 days ago

    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.

    • Flipper@feddit.org
      0·
      14 days ago

      In a project I’m in there are 20 commits just labeled .. The only reason I haven’t slapped them silly is they left before I started.

    • 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.

    • GissaMittJobb@lemmy.ml
      0·
      13 days ago

      That kind of commit quality should only really be permissible on private projects, and as a reviewer, it’s arguably acceptable to reject PRs with this kind of history.

      You should be writing your commits to the benefit of the code reviewer - structure them in a logical fashion to tell the story about the changes you want to get merged.

      For non-trivial branches I usually soft reset to the point where all code is unstaged and uncommitted and then curate the commits to align with what the reviewer should be reading. It’s not uncommon for me to have several branches containing a single “wip”-commit which I amend onto while building up the full code for the branch.