Unless you go in with a byte editor, you can’t change Mercurial’s commit history. I didn’t say “fabricate”, I said “change”.

In git you also cannot change history of a commit. You can only create a new commit with a new history. You’re arguing about semantics which don’t change the end result.

The point is, with Mercurial it would be hard and the result would be utterly incompatible with any other clone of the repo: there would be no way to propagate your changes to other clones. With git, this is a standard workflow.

As the example under discussion demonstrates, it’s also impossible to propagate the changes to git clones. Since history changed, merging the pull requests shows all the differences. That’s how Linus noticed the issue.

Well, that’s kind of his personality though.

Yes. Linus is known to overreact and use colourful language.

If it was compromised account trying to sneak code into the kernel, the attacker wouldn’t rewrite history since that would be obviously flagged when Linus tries to merge the pull request; as demonstrated by Linus in fact noticing the rewritten history. There was virtually no chance that this was an attack.

Unless commits are signed, you can always rewrite history. No matter the tool. Extreme example demonstrating that this is possible is the fact that I can change my machine’s time, change my user name and reply the tool’s commands to construct whatever history I want.

It was in fact a microscopic deal. Linus overreacted. Lemmy and Reddit milked the drama.

find -type f -exec chmod 644 -- {} +
find -type d -exec chmod 755 -- {} +

will only affect regular files and directories. There are other type of files (specifically block and character devices, named pipes and sockets) which those two commands would leave unaffected. In practice, I suspect you don’t have any of those to worry about so you can use -find f.

So does it wait until it has found all the matches to run the command as a giant batch instead of running it as it finds matches?

Indeed. If possible, it is typically what you want (as opposed to find ... -exec ... {} \; which runs command for each found file) since it will run faster. You want find ... -exec ... {} \; if the command you’re executing can run on single file only or you’re dealing with legacy system without -exec ... {} + support.

But I need x on directory, because that’s required to enter/read the directory. If I understand properly.

That’s why bacon listed find ${path} -type d exec chmod 750 {}; as first command. See also my reply.

X applies to directories and executable files. Presumably, OP wants to clear the executable bits from any files and +X won’t do that.

As root:

cd /filesystem/in/question
chown myuser:media -R /filesystem/in/question
find -exec chacl -B -- {} +
find -exec chmod 644 -- {} +
find -type d -exec chmod 755 -- {} +

This is not a legitimate issue. It’s like complaining that wget reads proxy settings from /etc/wgetrc. It’s absolutely proper for programs to read system- or user-level configuration if the configuration is not specified via environment variables or command line options.

The typical setting hierarchy goes something like:

• command line options,
• environment variables,
• user-level configuration files and finally
• system-level configuration files.

uBlock Origin and mouse copy and paste works perfectly well in Firefox.

Switch to a non-buggy browser.

My approach is to define custom keymap and enable it in xinitrc. Might be worth a try though I’ve no idea how that interacts with Wayland.