Hacker News Reader

Comment by WolfeReader | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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

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.

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

I take a similar approach where I have branches named `my_feature/x` where I start with `my_feature/1`, do some stuff and make a messy commit history, then when I feel like I want to clean up the commit history I branch of that to `my_feature/2` where I rebase/squash/reorder/rewrite away and continue from there. That way if I lose something important I just go back to an earlier branch. for complex features I can easily get to 15 of these branches. And I just delete them when I'm done.

I find this works really nicely, I can periodically clean up my commit history and do a full review of my changes so far and make sure they're all coherent before continuing. And doing this regularly makes it much easier to keep the commits nicely self contained. It's like `final_version_final_ii_for_real_final.xlsx` on top of git

No I was just lazy.

Reply on news.ycombinator.com