The kitty graphics protocol lets you send images to display in the terminal. I had a play around with it trying to make a similar GUI. The big gotcha is text rendering. You can either stick to normal grid aligned monospace, or I think you could maybe use a texture atlas, but it’s not going to be very efficient at all. I haven’t got as far as trying that though.
The videos… while they work are probably uncompressed video which is only going to work well over a very fast network.
You’ll always get downvotes for this from Linux apologists who didn’t have the exact problems you’re describing, but you’re 100% right. There are loads of things you might reasonably want to do in Linux that require a command line, or just don’t work well.
This should work out of the box!
How do you expect the system to know what program is important to you and which isn’t?
Hmm
The windows solution is to switch tasks very often and to do a lot of accounting to ensure fair distribution.
Sounds like you have a good idea already!
You’re right of course. I think the issue is that Linux doesn’t care about the UI. As far as it is concerned GUI is just another program. That’s the same reason you don’t have things like ctrl-alt-del on Linux.
No. And even worse is Linux’s OOM behaviour - 99% of the time it just reboots the machine! Yes I have swap and zswap.
Linux is just really bad at desktop.
Interesting I hadn’t heard of these “atomic” distros. There isn’t really much description of what exactly is atomic about them though - all you get is “The whole system is updated in one go”. Can you explain it?
Yeah I think RISC-V is probably still about 10 years away from being a sensible choice for a laptop. There’s a load of platform stuff around things like ACPI and Device Tree that’s still being decided. Also some ISA extensions that are standard on x86/ARM are either unratified or very recently ratified (e.g. Vector).
For microcontrollers it’s ready now, and for server applications it’s probably doable now and will be solid in a few years. Laptops & phones will be last though.
I was going to say there are about a gazillion free Git tutorials so this seems like a strange thing to charge quite a lot of money for. But it does look very well done.
Yeah I get what you’re saying. Gitlab can pretty much do that too, you just need a branch & MR for each commit, and then you tell it to merge each branch into the previous one. It automatically rebases them when their dependency merges.
Definitely more tedious to set up than just pushing one branch though. Maybe I should make a tool for that… Does Gerrit test each patch in CI sequentially or just all of them together?
But in any case that wasn’t really the problem I was talking about. What I’m saying is that whether or not you should squash a branch depends on what that branch is. Neither “always squash” not “never squash” are right. It depends. And developers seem to have a real problem with knowing when a change is important enough to warrant a commit.
Though I suppose if people have to actually review each commit they would get a lot more push-back to “fix fix fix” type commits so maybe you are right.
Does Gerrit require each individual commit to be approved or can you just approve the whole branch/changeset?
How does that help?
Yeah I agree but in my experience developers seem to struggle with “keep important things in history; squash unimportant things”. An open “merges allowed” policy leads to people unthinkingly merging branches with 50 “typo”, “fix” commits for a 100 line change.
Dunno what the answer is there.
you should spam git log --graph
Yeah… but that’s just a poor man’s GUI. Why use that when you can use a proper GUI? The only reason I can think of is if you happen to be in a situation where using a GUI is a bit of a pain (e.g. SSH).
Tbf I’ve been using Git for at least 10 years and I only just discovered this. I think nobody talks about it because it doesn’t show history which is 90% of the reason to use a Git GUI.
Yeah sure. git push says “did you mean git push -u branchname origin”. Yes obviously I meant that. I always mean that.
I’d been copying and pasting that for about 5 years before I discovered there’s a feature (auto branch setup or something) which means it will automatically do that. But it’s not mentioned in the error message! Why?
Git has a load of --fixed-behaviour flags like that that are just not on by default and never mentioned.
The terminology is very poorly chosen in a lot of cases. “The index”? Wtf is that? “Staging area” is at least slightly better but would “draft commit” have been too much to ask? Ours/theirs is also a stonkingly bad choice of words. How does Git know which code is mine? It doesn’t. Hell it isn’t even consistent about which way around they are.
Someone has force pushed a branch and I want to update my local ref (without typing the whole branch name again). git pull gives a wall of text without the answer, which is… git reset --hard @{u}. Catchy!
Or maybe I’ve got a branch that is tracking my fork but I want to pull from upstream. Can I do git pull upstream? Nope. I have to repeat the branch name git pull upstream branch-i-am-on. (Please don’t say "but git doesn’t know which branch you want to pull.)
Then there’s the error messages… Make a branch called foo/bar. Now try to check out a remote branch foo. See that nice explanation about how git branches are actually files and directories, not just strings? Nope? Huh.
This is just a few I can remember off the top of my head but it’s the tip of the iceberg.
They’re not that simple because of packfiles. But yeah loose files are very simple. Also the documentation for packfiles is pretty bad. You end up reading other people’s random notes and the Git source code. (I actually have written a Git client from scratch.)
I tried to follow tutorials that use the command line. In hindsight that is terrible way to teach Git, which is fundamentally quite a visual thing.
It’s like trying to teach people about filesystems only using cd, ls and pwd instead of just showing them a file tree.
Actually it’s even worse because Git’s CLI is so notoriously awful.
Eventually I tried Sourcetree which made it all make sense. Though Sourcetree isn’t a very good GUI, mainly due to being hella slow. I eventually switched to GitX which is probably the best GUI I’ve used so far and makes everything extremely clear and easy. Unfortunately Mac only.
I now mostly use the Git Graph VSCode extension which is excellent and integrates pretty well with VSCode. Unfortunately it has been abandoned by its author and they frustratingly included a license clause saying only they could release versions of it, so it’s basically abandonware. But it still works so I’ll figure out a replacement when I have to.
I’ve tried them all. Didn’t get on with Sublime Merge.
My recommendations:
Most of the others are kind of crap IMO.
Damn, I thought Google used to do that and changed it like 10 years ago. Did Apple just not notice?
I would prepare a healthy supply of alcoholic beverages and maybe some antidepressants! Also clear your calendar so you have a few weeks to debug.