4 ms·

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

by 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).
mulmboy 2y ago
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

by dzaima 2y ago

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

mulmboy 2y ago

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