whatevah5982

This is a result of the popularity of Github. Low barriers are good, but as a result of this you're getting also inexperienced/low-effort people alongside the rest. And they're the majority. Github is so popular that it has become almost a one-stop shop for some users, while explicitly _not_ catering to non-technical users at all.

One thing that worked pretty well for me was to move to Gitlab. Very few people currently bother to create an account on another website to report an issue, and as a result the quality of feedback and reporting has always been very high. Gitlab has also less gamification, which helps in keeping project popularity from skyrocketing just due to stars and network effects instead of actual project merits.

I initially moved a single project when GH was acquired by Microsoft. GH/GL are totally equivalent for me, but due to this I ended up moving all my public projects and never looked back.

> a, it doesn't already exist in the destination, in which case you have no way of knowing that the previous-commit data is correct, because while tampering would change the commit hash, you don't know what the old hash was because you've never seen the commit before.

In a fork we validate the common ancestry. This is used so that you can diff from the last known commit to the current point in absolute terms instead of relative.

> b, it does already exist in the destination, in which case you have a perfectly good history for it already

Unless it has been rewritten. Which, in git, we know can also happen by mistake. In such cases we can argue that you can diff the entire source tree and narrow it down the point where you believe the history path diverges and spot the changes youself, but git makes it a little bit more convenient.

As a single developer or a team working in the same organization you can ignore this property, however in a distributed VCS it is pretty much a defining and essential feature.

Guaranteeing that the history is the same is paramount to ensure that the same operation on two repositories which are _supposed_ to be identical will yield the same results.

This is what allows you to merge back history from a forked repository over which you have no control with confidence.

You don't necessarily need that property, true. You also don't necessarily need to make it mandatory. However if you want to play in the distributed VCS game, you'd better have something equivalent that can give you the same guarantee.

The darkening is sufficient for regular cars, but it's almost useless when the headlight of the SUV behind you is at the driver's level :(

I bought my car used a while ago, and it's now ~10 years old. I find the stock headlights to be perfectly adequate to drive in rural areas (and I live/drive regularly rural streets without street lights).

The difference with newer cars though is _staggering_. It's not only SUVs.

I'm not sure that's enough. Newer SUV cars have headlights which are stronger and bluer already coming out of the assembly line.

When I have a SUV behind my regular utilitarian, I'm fully blinded. The higher headlights reflect directly both into the rear and side mirrors.

The strength is also overshadowing my own headlights (I see the shadow of my car in front of me).

When a new car is going in the opposite direction, I'm never fully sure if the driver just forgot the high-headlights or not.

Some years ago I was unsatisfied with my pay and I accepted the interview of a Giant Search corp, getting to the on-site interview. The lunch with random employees was perhaps the best part of the experience for me, as it became abundantly clear that a good chunk of devs that I had some conversation with outlined in very generic terms the same basic stuff everybody else needs to do in software: maintenance, basic infrastructure, scripts, and so on. Which is, you know, totally expected.

I'm pretty sure that everything is at scale and so on, but I couldn't shake the feeling that up to that point the stuff I would be working on was not on the table and I could be switching from a place where I like what I'm doing [biotech] to just a highly paid but plainly boring SE job.

This curbed my enthusiasm instantly. Up to that point in my career I always considered available positions based on the actual function I would be doing in the company, never vice-versa.

The afternoon sessions didn't work as well, and although I could still have some extra interviews through phone calls I cancelled them a few days afterwards.

I cannot say for sure what did I miss, but I am certainly totally disillusioned for Big Search as a company today due to it's consumer attitude that I no longer wish for a position there.