Because when Ferret7446 says "neutral", they mean "anything that doesn't harm them". Centrism is a lie.

probably not relevant to you, since it is yet another tool for managing your development environment, but maybe have a look at devenv (https://devenv.sh). it's main purpose is managing the development environment, but it has integration for pre-commit (or even prek iirc) that let's pre-commit do it's thing, but takes over the dependency management.

read the article, it recommends devenv or pre-commit as tools that do thr setup for you

Alas, neither works for me. I've not managed to find a Windows equivalent yet.

Edit: `git config --global core.hooksPath D:\GitHooks\` is what I needed!

zero delay on commit, but then an entire CI run and feedback loop just to fix a linter or formatting issue

The solution could be a pre-push hook. I am also not a fan of pre-commit hooks because I just want to commit my wip changes. Not stash. Commit.

It's fine if the auto formatting tool hasn't been run. If the pre-commit hook changes my files silently, that is a big no-no for me.

I have had tools break things before and it makes it very hard to work out what happened.

Having it fail to push means I get to choose how to fix up my commits - whether I want a new one for formatting changes etc or to go back and edit a commit for a cleaner public history.

I used to think pre-push was better than pre-commit but at some point I realized I was actually just kicking the can down the road and leaving bigger problems for myself. It's not downsides-free, but it's the better compromise for me.

100% agree on hooks being readonly.

Username oddly relevant to context btw.

I would argue that if the pre-commit hooks come in the way of rebasing, either the commit hooks are doing way too much (which is one of the points of the article) or you are creating broken commits during rebasing. If any of the commits you are rebasing is e.g. breaking formatting rules, they shouldn't have been committed that way in the first place.

I personally avoid pre-commit hooks and instead use git rebase -x "hook" to ensure my commits are not broken

I love hooks in general but I definitely have a thing against hooks that aren't read-only (except maybe some autogenerated stuff that "can't go wrong").

The hooks can fail my commit all they want, but I don't want them actually changing anything I've done, which definitely implies no reformatting in hooks.

maybe, because i really don't have the problem you're describing.

yes, formatters run on every commit. not only during rebase, but also every commit beforehand. if that is done consistently, the formatter does not cause merge conflicts.

merge conflicts during rebases due to variable name changes occur without commit hooks, too.

> if you have a hook that is designed to introduce said white changes at each commit of a rebase them you are going to have frequent merge conflicts.

Only if you rebase commits prior to the introduction of the hook. Otherwise that whitespace change should be already there in the old commits.

This is the first time I ever got ruby. Reading it always felt like magic to me and I think it's still too much, if I really want to understand the abstractions, which unfortunately I do. But the understanding of blocks and especially instance_eval has helped a lot.

I'm glad I helped a bit. I'm going to write a few more posts since I just started a job where I need to do Ruby full time. I'm writing about Loops today.

you're telling me my depth perception is not creating a 3D model of the world in my brain?

even ddg has integrated AI now and while it can be disabled, the privacy aspect seems to mean that ddg regularily forgets my settings and re-enables the ai features.

maybe i'm doing something wrong here, but even ddg is annoying me with this.

I agree it’s annoying that the setting seem to change all the time, but you can use noai.duckduckgo.com

Wow! Thank you for that url, I didn't know that. Changed my default search engine to this and am - finally - rid of ddg settings getting annoyingly reset all the time!

The settings don’t change, but they are stored in anonymous local storage, so if that is cleared they go away. If you use our browsers though this is managed through the browser.

Google hasn't really worked like you imagine for a decade.

then why did my keyword-based approach work better than the natural language approach?

Your version assumes that the user knows that luks exists in the first place, OP's does not.

OP specifically said they were looking for luks commands.

> mount luks encrypted file

Usually references hard drive articles and even AI slop that says same thing.

End of the first page, there's one link to something that solves it, so I might take this hint, thanks.

> luks file mount

This actually has a decent first link... so, yeah... cool

I've thought about getting a web browser to work on the terminal for a while now. This is an idea that hadn't occured to me yet and I'm intrigued.

But I feel it doesn't solve the main issue of terminal-based web browsing. Displaying HTML in the terminal is often kind of ugly and css-based fanciness does not work at all, but that can usually just be ignored. The main problem is javascript and dynamic content, which this approach just ignores.

So no real step forward for cli web browsing, imo.