308 karma · joined February 18, 2020
Sweden.
My wife and I are fans, but their Finland-Swedish Vörå dialect is not easy to understand, especially for us in the very south of Sweden. I have watched the recording too many times to count, and made these so she could enjoy it more.
At my job, we use it to backport upstream commits from vendors or other internal branches. If we just copied the contents (everything at once?!) and made new commits, it would become impossible to track and we'd end up with chaos.
Keeping the original rationale for changes is invaluable when trying to understand complex code. There are few things more frustrating than a commit that says only "fix bug".
As for other git commands, git bisect is wonderful.
This means that it's not legal to download a rip of e.g. a CD that was uploaded without consent, even if you own a copy.
(This exception to the general right to make copies for private use was added in 2005 to make downloading illegal -- previously, only uploading was infringing.)
I would assume just the act of downloading this content was illegal in the relevant US jurisdictions as well.
In high school, 1984 hit me hard.
As an adult, I'd pick Pojken som fann en ny färg (literally translated "The boy who found a new color"). I really liked it's ultra-short chapters, making up snapshots of a romance and family being built and falling apart.
I can't say, but I know that they have made wide-ranging changes to behavior, e.g. the in-kernel locks: https://www.kernel.org/doc/html/latest/locking/locktypes.htm...
The page goes on:
> A patch does exist to enable process to have real-time process access to any process requesting it.
According to the sched(7) man page, this has never been the case: before 2.6.12, the process had to have CAP_SYS_NICE; after, it was limited by policy through RLIMIT_RTPRIO. I guess it's possible that this was not the case for the original out-of-tree patch set.
But it's been there for many years, well before the 2020 edit that added the bulk of the current text on that wiki page.
It quite nicely demonstrated the difference in philosophies, albeit accidentally. :)
Bread rolls with bits of glass or metal in them, found in parks or along other pedestrian paths. They caught one woman doing it, but it is believed the news might have inspired other nutjobs.
Yes, any tablet worked, but it required running an app customized for the hardware. That only proves that we can standardize at the level of Android app APIs.
https://github.com/libexpat/libexpat/pull/789/commits is a PR of 16 related commits. Many of them make sense individually, but are depended on by subsequent commits.
Reviewing them separately makes sense. It's easier on the reviewer (and future readers) to handle multiple smaller changes, especially since each is more tightly coupled to a rationale in the commit message. Unfortunately, github's PR-focused UI doesn't really make this per-commit review as convenient as Gerrit does.
Additionally, the last two commits are authored by another contributor. This metadata would be lost in a squash.
Of course, each intermediate commit must build and pass tests. WIP and cleanup commits are squashed locally before final review/merge.
You could argue that all of these could be separate PRs, but I think there's value in grouping them up with that final merge commit, showing what one was trying to do at a larger scale.
I can install python-matplotlib from my package manager, and it appears in my python path. I never bother with venvs.
Maybe my needs aren't advanced (or exotic) enough.
Because they can explain their individual rationales, while still making the most sense to merge all together.
> What can you possibly learn from that that you can't get from looking at the entire diff the PR is introducing?
Ease of review (both before merge, and in the future when wondering why something was done a certain way). Saves me as a reviewer from having to guess which parts of the commit are meant to do what.
This, of course, means that every commit needs to be a reasonable change in itself -- fixup commits done while developing should be squashed into the original change with a local rebase (these are the "meandering" commits your parent post mentioned).
> How do you know/enforce that all the inbetween commits also build/pass tests?
I'm no CI expert, but I would hope that most systems allow this as an option.
> How do you know how many commits to revert, if you need to revert the feature? Instead of reverting 1, now you have to revert N where N is not recorded anywhere.
It's recorded in the merge, assuming you always make a merge commit.
Otherwise, since each commit is actually its own logical change, you figure it out the same way as you would figure it out in the "squash PR" model -- bisect to find it, then see if reverting it helps.
I also recommend it to git newbies, as a tool to understand the state of their repo when something has gone wrong (e.g. they did a bad merge or rebase).
I don't think it is. At least not that I can remember.
Interesting. That's the default by law here in Sweden, but can be negotiated with the union -- usually in exchange for better severance compensation.
And definitely Sweden. Many (most?) of my software engineer colleagues are members of either the engineering-specific "Sveriges Ingenjörer" or generic white-collar "Unionen" union.
That's what all striking members get. The extra 30% is meant to make up for benefits lost during the strike (e.g. retirement fund contributions and vacation day accrual).
The "special" thing they've done is to waive the waiting period that normally applies to new members, so that workers who do agree with the strike can join without to much financial risk.
> talking about sanctions against member employees who continue to show up to work
The sanction is expulsion from the union. Strikebreaking weakens the strike and the union, so that makes perfect sense.
(also, the sympathy strikers object to the hiring of other people _to do the strikers' tasks _, not hiring in general.)
> Force the price of labor to be high and unemployment will increase.
If you don't, there will be a race to the bottom and people won't have a liveable wage.
Besides, Tesla is claiming that their compensation is better than the the collective agreement's minimum, and if that's to be taken at face value, clearly the agreement's cost of labor isn't too high.
Members and non-members work together at the same companies, and the collective agreements between the unions and the employer organizations apply to all employees, not just members.
That would probably be difficult, as construction workers and related unions would presumably also join the sympathy strike. Electricians are already involved.
> more of cartels than worker collectives, and getting involved in another unrelated unions negotiation seems to cross that line.
It's in all the unions' interest to defend the current model. Sympathy strikes make sense.