4 ms·

Here ya go: commit f5b5bd8f9eaa443d4020cbe918x742e7ddd22000 Author : John Doe <John.Doe@mail.com> Date: Mon May 22 14:21:03 2023 -0400. merge

• yjftsjthsd-h 2y ago
  So? Even without good commit messages `git blame` will tell us who touched what and when.
  • dzaima 2y ago
    Not necessarily; if one commit touches all lines (or a bunch), and another reverts that, the blame is thrashed; much worse than having rebased the temp change away. And a commit name of "." is quite significantly less useful in a git blame than "Rewrite foo to use new thing" when looking at reasons for why foo might have broken.
• WolfeReader 2y ago
  Is the reuse of the commit hash and date intentional and part of the joke? Besides that, I like seeing and preserving this kind of history. And when I don't want to, there are ways to filter the logs.
  • falcojr 2y ago
    How is a "PR comments" commit useful to you? If I'm looking at history, it's usually to see: 1. What caused a bug 2. Context around a feature and why it was written a certain way Seeing a "PR comments" commit just turns into noise. It also makes me gather 10 commits together to try to piece back together the unit of work that was built. I just see no value in preserving this type of noise.
    • WolfeReader 2y ago
      That is a perfect example. The "PR comments" commit helps me see what the dev considered most important (code before this commit), and what the rest of the team considered lacking (the content of this commit). Thus, the Git history records a facet of the team culture at the time of the commit.
      • leoqa 2y ago
        In my experience the merge commit is simply a reference to the PR, which has all the context. The title of the PR is effectively the commit summary.
      • eviks 2y ago
        No, you're making up that story and that culture, and when you lose this spurious foundation, you'll just as easily make up some other story based on any other random data. For example, reality could've been that there was no team involved at all and all those changes came to the original person the moment he made the PR. And the "PR comments" could just as easily refer to his own comments he added during when checking those CI messages and noticing something else and commenting on that not to forget.
  • dzaima 2y ago
    For most things (or, well, that depends on what one commits I guess), the filtered form will likely be the more preferable one. If you want to keep around some of the largely-useless stuff just in case, you can `git tag backup/sso-garbage` or similar before rebasing. For fun, here's a git log pre-rebase of some backup tag I have (final commits: https://github.com/dzaima/CBQN/commits/eccbac37ab15bd68320d97c077373a65fc16a493/ https://github.com/dzaima/CBQN/commits/eccbac37ab15bd68320d9...): f6bc866f (tag: backup/pre-rebase-si-bitwiden) ..aarch64 0fd19c39 Singeli n→8 bitwiden ed2a0655 more Singeli utils 556aa17b use q_fbit more a28adcbb minor src/README.md cleanup d6d40fc7 .warning comment 9dcf2f75 .don't need customizeShape for explicitly-created bitarr 958a04a1 update Singeli submodule 159ee16e .. ea43cb2d . b067d7a8 !! c588a381 fix ⟨1‿2⟩⊸⊏˘ mat 0e251720 . 8f049ede fast inds⊸⊏˘bits for 4-bit & 2-bit input & output cells def8c196 fast inds⊸⊏˘bits for 8-bit input & output cells 1638f8d4 .valgrind false-positive hiding 1023aaa5 --replxx-read-only bee4169e .more valgrind improvement c3643fc6 use custom valgrind pdep/pext everywhere 45796542 fix out-of-bounds load on empty replxx line bc5894b9 make bitp_get & bitp_set load/store u8 instead of u64 3b4381b2 include last power of two in fast-path ⌽˘ Most of that didn't compile on aarch64 before that last commit, even changes that could affect aarch64 as I sprinkled in some other things while working on the "main" thing as they came up.