4 ms·

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 wa

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.
- WolfeReader 2y ago
  Yes, this is great! It's like I can see you coding, your process is captured in history. When I just want the end result, I can filter the logs or look at the merge commit. But this is valuable too - especially since you yourself might look back at it and remember not just what you wrote, but how.
  - dzaima 2y ago
    Filtering requires a filter to exist, which is time alternatively spent doing rebasing (esp. awful if you're not the one who wrote it and now have to make sense of the awful mess to achieve literally anything out of it). And that log contains like 4 completely independent things, which wouldn't ever make sense in a single merge anyway (unless you like awful merges of a bunch of random things thrown together in a random order, at which point reading the merge commit message now also requires scanning through and ignoring a bunch of unrelated things, and tracking which change corresponds to which commit named "."; never mind that a merge commit necessarily cannot relate notes to code changes as good as commits can; never mind that this requires a merge commit to exist in the first place, which too is time that can alternatively be spent doing nice rebasing). As fun as it might look, I'm fairly certain that the original commit contents are entirely useless to anyone who isn't me, and by this point they're pointless to me too. I'm fairly certain it's entirely pointless other than a trip down the memory lane (which, granted, can be quite fun, but is entirely not worth basing the primary git log around).
leoqa 2y ago
No I was just lazy.

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.

WolfeReader 2y ago
Yes, this is great! It's like I can see you coding, your process is captured in history. When I just want the end result, I can filter the logs or look at the merge commit. But this is valuable too - especially since you yourself might look back at it and remember not just what you wrote, but how.
- dzaima 2y ago
  Filtering requires a filter to exist, which is time alternatively spent doing rebasing (esp. awful if you're not the one who wrote it and now have to make sense of the awful mess to achieve literally anything out of it). And that log contains like 4 completely independent things, which wouldn't ever make sense in a single merge anyway (unless you like awful merges of a bunch of random things thrown together in a random order, at which point reading the merge commit message now also requires scanning through and ignoring a bunch of unrelated things, and tracking which change corresponds to which commit named "."; never mind that a merge commit necessarily cannot relate notes to code changes as good as commits can; never mind that this requires a merge commit to exist in the first place, which too is time that can alternatively be spent doing nice rebasing). As fun as it might look, I'm fairly certain that the original commit contents are entirely useless to anyone who isn't me, and by this point they're pointless to me too. I'm fairly certain it's entirely pointless other than a trip down the memory lane (which, granted, can be quite fun, but is entirely not worth basing the primary git log around).

leoqa 2y ago

No I was just lazy.