urxvtcd

I did try this mode some time ago and found it really inconvenient. Also I'm not a person to dismiss IDEs, and I never recommend Vim to anyone I know as a better way of coding.

No hard feelings, I see how you might have read that from my comment.

Heavy shell and vim user here, but I simply cannot imagine how this might be convenient. A bunch of readline-style shortcuts will do the job just fine. And they are everywhere. SSH, database prompts, even login screens support them.

The better phrase might be the "tar pit of immediacy", from the Unix chainsaw talk by Gary Bernhardt. Highly recommend: https://www.youtube.com/watch?v=ZQnyApKysg4

I think the GP is aware of that, and just decided it's too much of a hassle.

I used pass for few years, and have recently switched to bitwarden. I know my way around git well, but I just never remembered to push the new passwords from either my desktop or my phone, which sometimes made me reset the password on one of the devices, and getting conflicts later on, I was always forgetting the password to the SSH key on my phone, and was ever-worried that I don't understand shit about GPG. Two years ago I switched my laptops, and moving the password store to the new one was painful. I'm sure I did something wrong, and that someone who knows what they're doing would have no trouble doing that, but I guess it's not for me.

Also, a minor pain point is that generating a new password for an existing login overwrites the whole file, and not only the first line, so I had to copy the other login data from the old file to the new one. I'm sure there's a way around that, but I never bothered.

I once forgot root password to my FreeBSD installation, I spent a lot of time trying to remember it but failed. So I did a reinstall, and obviously recalled it when prompted to come up with a new one.

I always do L like Elisabeth and N like Enigma.

You just want to merge the repositories, there are plenty of guides online. You need to realize that git has pretty simple internals, so the procedure looks like this: 1. Inside one repository you add a reference to the other repository with `git remote add`. 2. When you do a fetch, git will just download all the objects from the other repository. 3. Then you check the files out and make commit. You can do it in a few ways, for example, you might wish to preserve tags from all the repositories, but put them in their own namespaces, so you don't get conflicts. I wrote an answer on SO explaining exactly this: https://stackoverflow.com/questions/1425892/how-do-you-merge...

I like to include the following line in my template:

    # Co-authored-by: Firstname Lastname <f.lastname@company.com>

so I can quickly uncomment this and fill in the name of the person that helped to author the change. It even is recognized by gitlab and github.

I have capslock configured to act as control when held down, and as escape when tapped. Best thing since sliced bread.

So the dash in `-czf` if optional? Which reminds me: why does ps have two sets of options again?

openssl reminded me of gpg, wow, this one is horrible, and manuals don't help at all.

Nearly everything that packs or unpacks stuff. tar, gunzip, and else. I can never remember if they are going to unpack everything into a subdirectory or spill everything into my home, and conversely I never know if after zipping there's gonna be a directory inside or not. Luckily dtrx and atool do the thing you want most of the time.

From the time I was a teen I think I remember that mount was difficult to use, and mounting a CD image required passing some arcane options, though maybe I just didn't know how to use it (on the other hand I didn't know how to use Daemon Tools either, and it just worked).

I don't have a problem with git though. I don't think it's the command-line interface that's hostile, it's git itself if you don't know what you're doing. After taking some time to learn it I actually enjoy solving difficult problems with git.

Ironic that the lines on the page are well over 200 characters.

Not a blog post, but a piece of Kurt Vonnegut's talk randomly found on youtube had an impact on me: https://www.youtube.com/watch?v=GOGru_4z1Vc

I'll risk giving an impression of being set in my superior ways: just type Ctrl-D as it suggests? It works for every readline-like environment, like shell, ssh session, redis cli, and so on.

Just remember that --force-with-lease only protects you from overriding commits you have not yet fetched.

It's also possible (if difficult) to recover files which have been git-added and not commited. The only files git can't recover are the ones that it hasn't registered in the first place.

> And if I push without first pulling

I think I know git well, but you got me confused. I've never heard of pushes causing merges. Surely you are talking about pulls, right?

I just looked it up and found this pdf[0] on some technique for divers I didn't bother to understand, but it contains an instruction (Step 3: Learn to control the soft palate) how to get a feel for this. It's not really nostrils, but I think this is what GP meant.

[0]: https://freedivewire.com/wp-content/uploads/2016/11/frenzel....

Hand grinders are quite nice return of investment, for the same quality of grind you can pay a lot less, because there is no engine etc. Also hand grinders have much less of a problem with retention.

You can also use part of commit message to find that commit, so if you want to fixup "Refactor foo", you can run

    git commit --fixup :/foo

I always wondered why anyone would do this. IMHO modality and shells just don't get along well. Besides that, readline-like bindings are both good enough and you're likely to encounter them in the wild when working with ssh, database prompts, and so on.

Not sure why you are being downvoted. You actually can use merge commits this way, by viewing the diff produced by

    git diff $merge_commit^...$merge_commit^2

when interested in whole change-set introduced by a branch or looking at individual commmits when interested in well, individual commits.

I'd disagree. The longer the branch to rebase the larger the chance of conflicts occuring.

I mean, yeah, maybe that's the reason, I don't know. Still, I see no reason why you'd split features and limitations into two distinct sets.

In Rust it's difficult to mess with memory: it's a limitation but also a feature. In Haskell you cannot mutate, a limitation if there ever was one, but also a feature.

No multiline lambda is a feature. It is convenient enough to use it like in

    sort(items, key=lambda x: x.size)

but really anything much bigger should have a name stamped on it dammit. I find JS largely unintelligible due to lambda overuse and nesting.

It's been a while since I last tried Vim emulation, so I don't remember the details, but I remember feeling impaired. :g and :v commands were missing, which is a big deal for serious vim users, I think?

Though comments under yesterday's post about scrollbars made me realize I might live in a :g/:v bubble :)

The author has a series on youtube where he explains the basics of astronomy in a very passionate manner. First episode here: https://www.youtube.com/watch?v=0rHUDWjR5gg

I wrote a very simple soup content downloader some time ago, you can get it here: https://github.com/urxvtcd/soup-io-downloader

It has some shortcomings, mainly content is saved under random file name without extension. Hm, maybe I'll try to fix that now.

The branches you rebase most of the time are your own topic branches, where you know what's going on. And they should be relatively short-lived.