skydhash

Magit doesn’t anything that is not readily available in git. Most of magit usefulness comes from “active objects” (meaning you can act directly on the report of some commands like git-log) and quick command construction due to transient and autocompletion.

It requires the same mental model as git.

The goal is to produce music, and such music is generally constrained by music theory. Using git is to version control some software, and version control is dependent on the programmer/team workflow.

At the team level, it’s guided by the release process, configuration management, which version is canonical. At the programmer level, it’s usually guided by how to switch between task, how easy to explore an idea and save the resulting experiment, how to reset the code to a know state and how to replay a previous changes on top of new changes.

So you discern what you want to do (which is independent of the tool), the learn how to use git to do them. If you start from git, you’re going to be confused, just like someone opening autocad with no knowledge of engineering drawing.

What is version control to you? For me it’s basically being able to store and retrieve snapshots of code at different instances of time, where each instance has its own significance. Checkout have a very precise meaning in that regards, just like add and commit.

Maybe you can explain how is it leaky based on your understanding of version control?

I would say “align the worktree (or part of it) to a specific state previously saved in the repository.”

The repository is a store, you check out the previously saved instance of a file, a group of files, or a subtree. In that regards, switching branches and restoring files is actually the same thing. A commit stores whole files and branches are pointers to commits (which update themeselves).

We usually don’t. We look at the harm/benefits ratio and if way too big, we usually ban them. Guns, various chemicals, explosives,… is not allowed for any random cases. I’m not calling for regulation but you can understand why someone prefer not to associate themselves with it.

> Computers have produced untold exabytes of spam. Hit pieces, security vulnerabilities and data leaks[...] massive increase in water and electricity consumption. etc.

Then you must blame cars and airplanes as mass murdering tools as well.

> He says “a lot of developers have not learned git IN DEPTH” and you respond by saying that’s not true because you’ve gotten away with just using a small subset

You forgot the “because it's actually kind of terrible from a UX standpoint”. My stance is against that. I haven’t learned git in depth because I never knew any other workflow than code and check in the changes. There’s not a lot of guides on how version control can help in the software development process.

It wasn’t until I got involved into OSS that I learned more which in turns give me the motivation to use and learn about git in depth. I’m also using magit (after a tour in various GUI) but for me it is to git what vi is to ex. Direct interaction instead of a command prompt.

Not really. Learning the piano and learning music theory is two different things but tied together. One is skill and muscle memory, the other is theory and understanding. It’s the same with git and version control. One is a process and the other is a tool.

I read many 400 pages books to learn various things about software development. So one more to learn about version control was worth it.

That's very much a credible scenario. I think I use code from SO in a single digit of occasions. But I use it a lot more for giving me insight like a keyword for doing a proper web search. Or the name of a flag for a cli command, or the general shape of an algorithm or what to check in a troubleshooting session.

I won't generalize, but it's very rare for me to need code as most of my diffs are either boilerplate (generated with a tool or copied from docs or samples) or core logic that is mostly the translation of some design that I've already spent hours or days on. My core issue has always been incomplete specs from Product or incomplete docs for some tool/sdk/library (alleviated by having access to the source code).

Generated code is just not that useful, especially when designing the core architecture of a new project. And later it's not that useful either as the specs (why and how) is more valuable than any code (what).

> I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint

Not really. I remember my early years with git and the favt was that I never needed more than clone, add, commit, pull and push. While I’ve done some mistakes that got ne to learn more, especially with creating branches and undoing. I’ve never needed a lot, even when I started using GUI which exposed more concepts.

Why? Because I have no understanding of version management and how it’s useful in a dev workflow/release process. I was just using it for checking in work.

Since then, I’ve read the “Pro Git” book, learned how devs and teams handle versioning and devel a good understanding of how git can help me in my coding process and general software development. And it’s very good at what it does.

I remember when I was scrounging memory sticks to get to 512 mb for my windows xp setup. And I was able to play Unreal: Return to Na Pali[0] on that.

[0] https://unreal.fandom.com/wiki/Unreal_Mission_Pack:_Return_t...

I gifted my sister my kindle this morning (it was unused for years) after loaded it with azw3 files converted from epub using calibre. The other options is to send epub via email. But I told her to never put it out of airplane mode and get it on WiFi because amazon has deleted my "documents" (that's what they called sideloaded books) before.

I own two kobos, a libra for fiction and an ellipsa for tech books and textbooks. Both have koreader on.

I'm using mu4e as my MUA and one the things that it offers are actions (something similar in mutt is macro) where you can map a keybind to some code that do something to the current message or the set of selected messages. This is generally the reason that a lot of mailing list recipients (high volume of messages) use those software, where you can refile messages very quickly leaving the more thoughtful reply things for later.

> Recent OpenAI/HuggingFace incident shows us that even in a very controlled top AI-lab setting, humans can't know what agents are really doing.

“very controlled” is disinformation.

I’ve been using vi (nvi) and mg and both doesn’t have syntax highlighting. I’ve copied a monochrome theme of github for my vim setup and my emacs config is using modus operandis which is somewhat minimal and muted.

While I can use rainbow color, but this day syntax highlighting kinda fades into the background as I don’t care that much. I like it for something like React and html for the tags part but indentation is much better than highlighting in my opinion.

That’s like one of two lines of i3status. Awesome if you need something like this one and built it. But don’t pretend that there aren‘t myriad solutions out there that have solved a lot of possible use cases.

I was watching one guy explaining the xv6 code and it was pretty much one shot with a single camera pointing at the listing on paper. Not sure if you need professional video if you want to really expound on something.

> etc. the list is endless.

Why is the list endless? I don’t even remember the last time I check or change any on my mac settings. And my unix things haven’t been touched in months. My debian server is basically frozen at this point.

> How you came to the decision to write the code in a certain way is certainly an important artifact of the development process. Otherwise how would your coworkers know whether or not a particular piece of logic is still relevant

Not really. Why is always more important than how. Even what is more important. Relevancy of a particular block of code is in the specs and some technical aspecs of computing/library/platform, not in the thought process of the developer.

Isn’t WSL2 vm based?

I think there are notes that warn you about the consequences. And they have been written with sys admin in mind which knows about user groups and security.

> Bug: this blog has no max-width. Lines of text will grow infinitely long with width

Are you maximizing your browser’s windows?

Why wouldn’t it be? If you were in charge of writing a letter and use words that hinders the purpose of the letter, thus resulting in a flawed communication, wouldn’t it be your fault? Especially when dictionaries are easily available?

> Seriously, this was a huge thing in C and C++, where you had to know/remember/know to look up very specific error codes and conditions in an API and if you didn't then it was very much considered to be a skill issue.

It was not unless you were part of some very weird circle. There was always manuals and other references that listed everything about a platform or library. Then we got ‘man’ and ‘info’. And I remember being able to download the full docs of windows’ various documentation.

That’s like saying as a writer you were looked down at because you had to look at a dictionary every once in a while.

I think projects today are too trigger happy about updating dependencies and using dependencies that are too volatile. IIRC, the task runner just couldn’t be built on debian 12 because its rust package was too “old”. Just two years have passed since the version freeze.

I think the appeal of tree sitter is to have a single query api for traversal of the nodes in the abstract tree of the language. So it become easier to adjust or adapt the parser.

Should they install make for you too (default command for compilation-mode) or the various sql client (for the sql-mode) pr a lisp runtime (for the repl)?

> I always tell people "Give me any task, and I'll find a better tool than Emacs." And "If you want to get up and running quickly for your task, Emacs is not a good choice." Followed by "What makes Emacs worthwhile is you get it all in one package where they can interact with one another." And "It's a lifelong journey."

That is the proper response. These tools are designed for someone that does need them as they are, not for someone that just need some tools. Software like vim and emacs are in fact a whole workshop that you need to make your own. If you just want a tool, there are better software out there, but people that usually go for emacs wants a workspace, not just one tool.

You might just as well require a sqlite db as the persistence layer. Emacs has always been about using plain text files as both data and interface while lisp is the control mechanism.

That’s why you got org files and a handful of lisp functions to turn them into a living documents. Using lists take that aspect away while markdown is just not that good to serve such a role.