lucasoshiro

Other difference (actually, more like a consequence of what you said) is that Git keeps reflogs for branches but not for tags

Agreed. If they don't care about the history, they don't need a vcs. There's no point in keeping a history if the history isn't helpful

> Maybe consider putting your energy into a good documentation inside the repository.

Commit messages are documentation.

If you have a good commit history you don't need write tons of documents explaining each decision. The history will contain everything that you need, including: when and who changed the code, what was the code change and why the code exists. You have a good interface for retrieving that documentation (git log, perhaps with -S, -G, --grep, -L and some pathspecs) without needing to maintain extra infrastructure for that and without being cluttered over time (it will be mostly hidden unless you actively search that). You also don't need to remember to update the documents, you are forced to do that after each commit.

And that's not a hack, Git was made for that.

> They're all using it, all the time, for everything

Do you know someone? Using Firefox nowadays is itself a "super-online bubble"

Clojure seems to be pretty strong. At least here in Brazil, several companies here use it as their main programming language

> Clojure solves the same problems Rust solves in a much simpler way

I'm curious about that, can you elaborate? I'm a beginner in Clojure and I only know a few concepts about Rust, but it seems to me that they solve (at least, currently) very different problems...

I only saw Rust being used in places where C or C++ would be used in the past (Linux kernel, CLI apps, desktop apps), while I only saw Clojure being used as a modern and functional Java and JS replacement.

Not to mention how different they are as languages (static vs dynamic typing, native vs jvm, borrow checker vs garbage collection)

I wrote a text about that:

https://lucasoshiro.github.io/posts-en/2024-04-08-please_don...

Ideally, we should write bug-free code, but we can't. There are some tools to avoid bugs, tests are one of them. Those tools avoid them, but not mitigate. Bisect doesn't replace tests, it only helps find where the bugs are happening. After finding and fixing the bugs, it's a good idea to write a test covering that bug.

To sum up: bisect and tests are not in opposite sides, they complement each other

Git has some really good tools for searching code and debugging. A few years ago I wrote a blog post abot them, including bisect, log -L, log -S and blame. You can see it and the discussion here: https://news.ycombinator.com/item?id=39877637

That's a niche case. And if you need to frequently SSH into a lightweight server you'll probably will be ok with the default commands even though you have the others installed in the local setup.

> You’re accustomed to a replacement command-line tool?

Yes.

> Then your muscle memory will punish you hard

No.

I'm also used to pt-br keyboards, it's easier to type in my native language, but it's ok if I need to use US keyboards. In terms of muscle memory, keyboards are far harder to adapt.

A non-tech example: if I go to a Japanese restaurant, I'll use chopsticks and I'm ok with them. At home, I use forks and knives because they make my life easier. I won't force myself to use chopsticks everyday only for being prepared for Japanese restaurants.

> bat it's a useless cat

I can't see bat as a "useless cat" or a replacement for cat except for reading source code in the terminal. It's more a like a less with syntax highlight or a read-only vim.

> that if you ever change your OS installation

apt-get/pacman/dnf/brew install <everything that you need>

You'll need install those and other tools (your favorite browser, you favorite text editor, etc) anyway if you're changing your OS.

> or SSH anywhere

When you connect through SSH you don't have GUI and that's not a reason for avoiding using GUI tools, for example.

> even use a mix of these on my personal computer and the traditional ones elsewhere

I can't see the problem, really. I use some of those tools and they are convenient, but it doesn't matter that I can't work without that. For example, bat: it doesn't replace cat, it only outputs data with syntax highlight, makes my life easier but if I don't have it, ok.

I wouldn't trust that... If you by mistake run `git clean -xfd` in your home, well, you know what happens

Do you have more information about it? By googling "Linux platypus" the only thing that I could find is that exact URL

I'm also used to Spotlight. One of the reasons is because I also use KDE and krunner has the same keybinding and almost the same functionality. But I still liked Launchpad (just like the app dashboard in KDE) as it shows me visually what I have installed.

Why? Well, there are some apps I have installed and forgotten, for example, I have several 3D printer slicers, but normally I only use one. I grouped them into a folder, so I could check what I have installed if I wanted to switch for whatever reason. I also had a folder called "useless", where I place everything that I don't used but I can't remove (Apple stuff, Safari extensions, bloat installed with LaTeX, and so on).

The new "apps" can't be organized. Everything is just thrown there, only sorted alphabetically. There's no reason for me to use that, if I remember what I want I can just type in Spotlight

PS: It's possible to bring back Launchpad in Tahoe through the command line. I only didn't that yet because I don't know how safe it is to do that.

Agreed. And if someone is interested in contributing to the Linux kernel, a new programming language is far from the hardest thing that they need to learn...

> Normal users who have to install the Rust toolchain to build a previously simple piece of software do not count.

"Normal users" would just install the same way they already do today without bothering about the toolchain.

"Normal users" who want to build by theirselves probably won't find it too difficult. Given the size of Git it's incredibly easy to build: just install the dependencies and run `make`.

> Is there a real difference?

The main differences are related to packages. The package format (.deb, .rpm, etc), the package manager (dpkg/apt, pacman, dnf, etc), how frequently the packages are updated, if they focus on stability or new features, etc.

New Linux users that are used to Windows or Mac sometimes dislike a distro and like other, but actually what they really disliked what the desktop environment. For example, Kubuntu uses KDE Plasma as its desktop environment and its user experience are almost the same as Fedora KDE, Manjaro KDE, OpenSuSE and so on, while it's very different to the default Ubuntu (that uses GNOME). But, under the hood, Ubuntu and Kubuntu are the same (you can even uninstall KDE and install GNOME).

Actually, other Unix-based systems can install the same desktop environments that we have on Linux, so, if you have a FreeBSD with KDE you won't even notice the difference to Kubuntu at first, even though it's a completely different operating system.

tl;dr: there's a real difference, but from a user perspective it's mostly under the hood, not exactly in usability.

You can propose this to the Git mailing list. I don't think this kind of feature should be respnsibility of Git, however, you can try

> it's just incomplete

Why?

> The Linux kernel developers have been using that workflow for a lot of time

Yes, they do. Git itself is also developed that way.

Btw, you don't need to use format + send-email, send-email calls format-patch under the hood

There are many approaches. For example, constructive solid geometry, where you use boolean operations on simple 3D shapes to create a more complex object. Another one is the extrusion of 2D shapes, which adds volume to 2D shapes.

My main tool is OpenSCAD, as I am a programmer and I model for 3D printing, which support both CSG and extrusion, but not the mesh manipulation like Blender.

One paradigm is not better than the other. Blender is nice for modelling, for example, characters, but it's really painful for doing precise shapes. For modelling multi-part action figures for 3D printing you'll need both things, sometimes modelling something in a tool and finishing it in other

"OpenAI, Anthropic, Google and more", where "and more" = 0. Where's Gemma, DeepSeek, etc?

The UI, however, is really clean and straight to the point. I like the interface, but miss the content

A .dmg or at least a CLI instruction would really help

> This makes me wonder why Git can't just store an empty tree for empty dirs.

tl;dr: it can (see my other comment) and the empty tree is hardcoded. But since the index works with file paths and blobs, having no file means that there's no entry in the index

It can store empty directories (actually, trees). It can't do normally because the index maps paths to blobs, an empty directory doesn't have a file to map to a blob and then `git add` will have no effect. Given that normally we write commits from the index content, then normally we won't find an empty tree.

You can run `git commit --allow-empty` with an empty index and the root tree will be the empty tree:

   $ git init
   $ git commit --allow-empty -m foo
   $ git rev-parse @^{tree}
   4b825dc642cb6eb9a060e54bf8d69288fbee4904

4b825dc is the empty tree. And a funny thing about it is that it is hardcoded in Git, and you can use it without having this object:

   $ git init
   $ git commit-tree -m foo 4b825dc642cb6eb9a060e54bf8d69288fbee4904
   $ tree .git/objects # you'll see that there's no file for the empty tree

This is a good reading about that weird object: https://matheustavares.dev/posts/empty-tree

Yeah, I wrote mine in Haskell. It's a good exercise for understanding how Git works

Also works great on Safari on a M1 MacBook Air, here

Something that I really like in Git is how its data structures are easy to understand and how transparent it is. It's possible to write your own "Git" compatible with existing Git directories only by reading how it works under the hood