commit f5b5bd8f9eaa443d4020cbe918x742e7ddd22000
Author : John Doe <John.Doe@mail.com>
Date: Mon May 22 14:21:03 2023 -0400.
merge main
commit f5b5bd8f9eaa443d4020cbe918x742e7ddd22000
Author : John Doe <John.Doe@mail.com>
Date: Mon May 22 14:21:03 2023 -0400.
fml
commit f5b5bd8f9eaa443d4020cbe918x742e7ddd22000
Author : John Doe <John.Doe@mail.com>
Date: Mon May 22 14:21:03 2023 -0400.
fix 2
commit f5b5bd8f9eaa443d4020cbe918x742e7ddd22000
Author : John Doe <John.Doe@mail.com>
Date: Mon May 22 14:21:03 2023 -0400.
fix 1
commit f5b5bd8f9eaa443d4020cbe918x742e7ddd22000
Author : John Doe <John.Doe@mail.com>
Date: Mon May 22 14:21:03 2023 -0400.
CI fix
commit f5b5bd8f9eaa443d4020cbe918x742e7ddd22000
Author : John Doe <John.Doe@mail.com>
Date: Mon May 22 14:21:03 2023 -0400.
PR comments
commit f5b5bd8f9eaa443d4020cbe918x742e7ddd22000
Author : John Doe <John.Doe@mail.com>
Date: Mon May 22 14:21:03 2023 -0400.
Linter
commit f5b5bd8f9eaa443d4020cbe918x742e7ddd22000
Author : John Doe <John.Doe@mail.com>
Date: Mon May 22 14:21:03 2023 -0400.
Fix test
commit f5b5bd8f9eaa443d4020cbe918x742e7ddd22000
Author : John Doe <John.Doe@mail.com>
Date: Mon May 22 14:21:03 2023 -0400.
Implement new SSO feature
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.
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.
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.
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
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).
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.
Get a long monitor arm and pull the monitor out from the desk. Mine sits almost flush with the desk, with my arms going underneath to the keyboard/mouse. This helped me remain sitting upright without leaning forward.
I'm legally blind (I'm very nearsighted, to the point where I need to be within an inch of the screen to see it), and this is basically how I use my computer comfortably. I have my monitor arm mounted to the front of the desk, to the left of my monitor. This allows me to have the monitor slightly out from the front of the desk but still put my hands under it to the keyboard. This does create some awkward situations though, like using a webcam is challenging because I'd need to push my monitor back but then I can't see it! I usually put the camera off to the side on the rare occasions that I need to be on video.
Have you been to an optician recently? I was finding myself leaning in, then had a test earlier this year and, well, now I have a (very mild) prescription.
I've have been prescribed +.5 a long time ago, more than 15 years ago I think. Was warned that once you go forward you cannot go back. I am still not wearing glasses though my vision for small fonts has took a serious hit lately. Back then I had excruciating headaches but Flux fixed that so I chose to forego the prescription.
That's interesting. If I wear & don't wear too much in a day I do get a headache, but I think if I don't at all then (until I do) it's fine so far.
The main thing that would stop me now is the reminder of what everything should look like - the world was very slightly blurred so gradually that I didn't notice, but now I put my glasses on and it's like switching to 4k.
I suspect every organization is as secure as its least secure/capable decision maker.
It's a scary thing as all you have to do is add one decision, one ignorant person and it's bad news.
I've worked in orgs where we made big leaps in security, very proud of our work. Then one ignorant person who had the authority made a decision with no valid benefit to anyone, completely compromised everything.
Seen it time and again.
Not sure if that was the case as far as the credentials went in this situation, but it always seems to be the human element as far as curious choices goes.
Depends on the focus group. Some are put together too establish that a product is wanted. Those are junk and useless. Others like this are designed to tease out trends and their accuracy is very valuable to the companies that commission them.
Uhhhh, in general this is true, but in this particular scenario they have a stronger incentive than almost anyone to understand true preference shifts created by these drugs.
It doesn't mean they end up with the correct findings, but they are absolutely incentivized to try to produce correct findings.
Lazy and inapplicable heuristics are not legitimate insights.
How many police officers do you know? Have you been on a ride along or attempted to understand their job?
Swatting victimizes the police as well, they’re responding to a potential hostage situation and do not have the benefit of hindsight. I guarantee these officers are horrified that the man was innocent and frustrated that they were put in this situation.
I encourage everyone who is adamantly “ACAB” to go on a ride along- contact your local department. At best, you get first hand experience to justify your beliefs and can virtue signal even more to your friends. Or you may be able to humanize the police.
> I guarantee these officers are horrified that the man was innocent and frustrated that they were put in this situation.
How many cops do you know? They might say they're horrified to the media, but that's not how they operate when no one's watching. There's a reason these SWATting events keep happening: cops enjoy them just as much as the SWATters do. They get to bust out their fun military surplus toys and do their SEAL Team 6 cosplay. If they wanted to stop these SWATting events, they would have found a solution by now.
Check out these highlights (lowlights?) from the Minnesota Department of Human Rights investigation of the Minneapolis Police Department:
Do you know why ACAB? Is not because they are rude, it's not cause they mean. It's because they participate in a societal role that requires them to do bastardly things.
They have to enforce unjust laws and unjust outcomes, and statistically do so more heavily across minority populations.
The institution requires them to be bastards, ACAB is a statement about the institution of police and the people who elect to join that institution.
> It's because they participate in a societal role that requires them to do bastardly things. They have to enforce unjust laws and unjust outcomes
The problems with American policing aren't merely that the cops have to enforce the law.
It's the qualified immunity, the get-out-of-jail-free cards for their buddies, and the dog shootings.
If the police never shot the wrong guy, always replaced your door after breaking it down, and were polite and apologetic when a mistake was made - people in this thread wouldn't be equating swatting with attempted murder.
Yes, they can't charge him again for the same physical act.
His federal guilty plea appears to admit to 375 swatting calls. So I don't think the state or local courts can subsequently charge him for any of those calls - they would need to find evidence of some separate calls.
I had an interesting problem occur to the pg stats. We were migrating and had a version column, I.e key, val, version.
We were migrating from version 1 to version 2, double writing into the same table. An index on (key, val, version) was being hit by our reader process using a where clause like key=k and version=1.
When we flipped the reader to read version 2, the latency jumped from 30ms to 11s. Explain showed a sequential scan even though the index could serve the query. I was able to use MATERIALIZED and reorder CTEs to get the planner to do the right thing, but it caused an outage.
We were autovacuuming as well. I ended up deleting the old version and rebuilding the index.
My theory is that because the read load was on 50% of the data, the stats were super skewed.
Orthogonal rant: Podman allows host mounts during image build, whereas docker does not. Ran into a big headache where a monorepo using podman leveraged this to create container images from source and the equivalent docker implementation had to copy the monorepo into the docker build context every time.
We needed to use Docker for M1 support (probably should've tried Colima, etc).
reply