The "watchlist" made me a bit uncomfortable. I get that it's satire, but putting real people's names in a list of people you're (even jokingly) watching for fraud, and assigning a "risk factor" to them (even/especially if they acknowledge it's made up) borders on defamation in my book.
I think in the US we already have that; it's just that our current leadership is in love with oil and gas and thinks renewables are "woke" or something. The number of renewable energy projects that have been cancelled or stalled here in the past year+ is gross.
It is nice that some Trump supporters are seeing prices at the pump and are having second thoughts about their Dear Leader. But a) it's disappointing that that's what it takes, and b) he still has a rabid base of people who love him despite his policies being the exact opposite of what they need to prosper (not to mention many of his policies being the exact opposite of what he campaigned on).
So we can only assume that renewables will continue to be kneecapped in the US at least for the next ~3 years. Hopefully European countries are fast-tracking renewable projects, but those things take time to build and bring online. (Hopefully they've been doing so since the Ukraine war started, really. The current Iran-related energy crisis is bad, but it's not like Europe had been sitting pretty with energy resources a month ago.)
> The unsafe versions of these things literally throw out history and replace it with a fiction that whoever did the final operation wrote everything, or that the original author wrote something possibly very divergent from what they actually wrote.
When I'm rebasing my own work and editing history, that's exactly what I'm looking to accomplish, though.
The team I work for tends to use GitHub's "Squash and merge" button a lot. I find it to be the best of both worlds: the `develop` branch gets a single commit per PR, with a summary of what was done (I always edit the summary commit message and reduce it from a copy of 20 commit messages down to just the most important 4-5, deleting the entirety of messages like "fixup" or "address review comments"). But the PR on GitHub also preserves the history of the commits, so anyone who wants to look at the messy commit history can follow the PR link and see the actual commits.
I'm sure there are other Git forges that would support a similar workflow, with a "Squash and Merge" button or equivalent, but my team hasn't felt any need to migrate away from GitHub so I've never yet investigated that in detail.
Only downside I've found to this workflow is that it would make it harder to migrate to a different Git forge in the future: unless you're very careful with the migration, the PR numbers are likely to be different (perhaps resetting at 1, even) and the other forge won't end up with the commits that are on GitHub's copy of the repo but no longer on any active branch (we also use the "auto-delete branches when you hit the merge button" option). But it would still be possible for a migration tool to handle this correctly: look at all PRs on GitHub, grab the commits from them, and migrate them to Merge Requests on the new forge.
It boggles my mind that instead of this being a UI projection, git instead ingrains a process where developers habitually destroy their history (and bisection options, and merge conflict resolution), therein loading an additional footgun that goes off every now and again when it turns out a now-squashed branch was the basis of (or merged into) some other branch
It’s important to note that not all history is worth keeping, and keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one.
I very much prefer keeping histories by default (both my personal workflows and the tools I build default to that) but squash is a valuable tool.
> keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one.
How so? When I bisect I want to get down to a small diff, landing on a stretch of several commits (because some didn't build) is still better than landing on a big squashed commit that includes all those changes and more. The absolute worst case when you keep the original history is the same as the default case when you squash.
> Because they’re broken and their only purpose is to fix up the original change, so it’s functionally the same change.
Do you restrict yourself to 1 non-broken commit per PR? I don't, and nor does anyone I've worked with. If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win. (If you didn't care about that sort of thing you wouldn't be bisecting at all).
> No, now you have a bunch of worthless broken commits that you need to evaluate and skip because they’re not the problem you’re looking for.
What are you "evaluating"? If you want to ignore the individual commits and just look at the overall diff that's easy. If you want to ignore the individual messages and just look at the PR-time message that's easy too. Better to have the extra details and not need them than need them and not have them.
> Do you restrict yourself to 1 non-broken commit per PR?
No. To the extent that I can however I do restrict myself to only non-broken commits.
> If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win
It is not a significant win when the bisecting session keeps landing me in your broken commits that I have to waste time evaluating and skipping.
And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already, so you’re increasing the total diff size you have to evaluate.
> What are you "evaluating"?
Whether the commit is the one that caused the issue I’m bisecting for.
> If you want to ignore the individual commits and just look at the overall diff that's easy. If you want to ignore the individual messages and just look at the PR-time message that's easy too.
Neither of these is true. git bisect (run) lands me on a commit, it’s broken, now I need to look whether the commit is broken in a way that is relevant to what I’m seeking.
> Better to have the extra details and not need them than need them and not have them.
Garbage is “extra details” only in the hoarder sense.
> It is not a significant win when the bisecting session keeps landing me in your broken commits that I have to waste time evaluating and skipping.
Skipping a commit that doesn't build is trivial (especially if you're automating your bisects).
> And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already, so you’re increasing the total diff size you have to evaluate.
If you feel the need to rebase to squash one-liner fixups into the commits they fix then that's a more subtle tradeoff and there are reasonable arguments. But squashing your whole PR for the sake of that is massive overkill.
Yes, a good Git log viewer that would auto-squash branches down to a summary, and allow "expanding" them, would be useful. But the way branching and merging creates confusing train-track graphs is IMHO one of the reasons why many teams end up using the squash-and-merge workflow. There's definitely room for improvement there...
Git doesn't do that. People needlessly destroying history do that.
Git will happily let you merge branches and preserve the history there. GP seems to like that history being in PRs only on github instead. I don't get why, that just seems worse to me.
That is an issue of ignorance, not laziness. It’s not obvious at all to an average developer that only uses `add/commit/merge/fetch/push/pull/rebase/restore/reset` that they can manipulate their change history.
I would assume most people who would enable an "auto squash" option also aren't carefully creating and curating commits. Bisect is useless if half your commits are broken. People regularly make commits that don't even build, much less pass QA and deliver a valid version of the software. These are works in progress, broken versions and should be deleted.
If you actually do like to deliver the correct number of commits then it's frustrating to work with people who don't care. In that case I would suggest making the squash optional but you could also try selling your team on doing smaller commits. In my experience you either "get it" or you don't, though. I've never successfully got someone to understand small commits.
> I would assume most people who would enable an "auto squash" option also aren't carefully creating and curating commits.
Or don't have a choice. Our department-wide rules were almost to require that for all repos, I had to push hard just to make it "strongly suggested" instead.
I would say yes, that's a good way to make the distinction. It's even more than that: the feed is different for every single user.
With a site like HN, everyone sees the same front page at a given time. What makes it to the front page is primarily determined by all users voting up articles or moderating them. Yes, there's some algorithmic sauce behind it that weights votes and flags differently based on some other criteria, but the dominating factor is user votes and flags. And, again, everyone sees the same ordering of articles if they load the page at the same time.
HN is centered around topics and articles. Social media is centered around individuals and what they personally choose to post and promote.
Agreed. There are lots of people posting shitty things on Facebook, Twitter, etc., but on LinkedIn, everyone is so fake. They're putting their best professional face on, heavily self-censoring themselves, and their content plays to the whole "employment culture". It's not even a little bit genuine.
> It's more than just procedure or habit, your hands feel dirty and you want to wash that off.
I'm not sure that's reliable across people. I'm definitely like that; whenever my hands feel the least bit dirty or oily or anything, I really want to wash them. But I've run into people who have commented on the fact that I do that, and I've learned that there are lots of people who just don't have that compulsion at all.
My point is that changing gloves is something that is even less reliable and needs to be drilled in through procedure and habit. Handwashing also needs the procedure and habit, but it has the added benefit that for a good number of people there's also a physical compulsion that goes along with that procedure and habit.
reply