I mean, you can use tabs consistently within a project. The only thing I’m aware of that actually bans tabs is YAML and… well, you can go a long way by always doing the opposite of what YAML does.

That said, consistency trumps philosophy.

If only we had collectively agreed on a number of spaces! Sadly it seems split fairly evenly between 2 and 4 so we don’t even get consistency.

IMO it’s because open source developers commonly use editors that have poor support for tabs, like Vim and Emacs.

Tabs are definitely better but to use them properly you do really need a “visualise whitespace” option enables. Emacs does it like this and Vim like this. Both awful.

Possibly also a bit because tabs for indentation, alignment for spaces is just too complex for most developers. Hell most can barely even get spaces right. I work in a couple of languages without an autoformatter (e.g. SystemVerilog) and some of our files are a joke. A mixture of 2 and 3 space indentations, sometimes on the same line!

It’s not a step further. They just picked 0 twice instead of 0, 1, 2, 3…

It’s just this: https://westling.dev/b/extremely-linear-git

Yeah it’s probably impossible to get a perfect diff in every case, but that’s irrelevant in the same way that the halting problem is true yet formal verification still exists. We don’t need perfect, we need “good most of the time”.

For example the “slider” problem has existed in Git forever, and apparently there are algorithms that mostly solve it (indent-new), yet Git still doesn’t use them. That repo is 9 years old. I can’t remember what led me to that but I think it was one of the new VCS’s saying they do well on that benchmark (can’t find any reference to it now though).

Pijul should also give better diffs in theory because it actually tracks lines as objects, so it has more information to work with. In the first example in diff-slider-tools it would know the difference between /* and /*. I haven’t actually tried it though.

There are also a few semantic diffing tools that understand syntax that could be integrated - notably Difftastic and Diffsitter.

Point is, it could easily be better than it is.

Yeah even though it definitely has flaws (awful CLI, dumb diff/conflict algorithms) and half-arsed parts (submodules, LFS), it really is pretty great software.

Still, I’m hopeful for the next generation VCS’s - Pijul, Sapling and Jujutsu.

I used to use Git stash but I found in the end I found just making “real” commits was better.

I haven’t actually used this site (found it after I already learnt Git), but it gets posted a lot, and one issue I feel like it has is it shows you the Git graph using a tool that you have to immediately throw away after you’ve finished this tutorial.

I think it would be better if it had an actual real Git tool shown. I would say VSCode’s Git Graph extension would be ideal but unfortunately it has a stupid license.

Not many people back up continuously, so this is still useful.

Well yeah I think the point is you’re human and you might make a mistake.

It is slightly surprising no? I can’t see any real reason for it to record this information.

That said, your rough timezone is probably going to leak just from the fact that people generally don’t make commits in the middle of the night. If you want HN paranoia levels of anonymity you need to schedule your commits to be automatically pushed at exactly midnight UTC every day.

There are use cases like monorepos where vdm won’t work.

Erm yeah because the whole point of monorepos is that you don’t use submodules. What?

Git does track submodule history unlike vdm.

The history of submodules is tracked in the submodule repo. VDM doesn’t change that.

It uses them.

It doesn’t use them any differently to if you had just checked out the submodule standalone. I’m not exactly sure what VDM does (haven’t used it) but that doesn’t seem like a big thing.

This is not how git submodules or subtrees work.

No?. Actually that’s not all you need to manage for git submodules - there’s additional hidden state so you can’t just edit that file; you need to use git add/rm. Which is fundamentally the same but worse - this is one of the selling points of the alternatives like VDM. It’s way less confusing.

Git submodules and subtrees don’t support anything other than git remotes.

So? Alternatives to git submodules don’t need to restrict themselves to its features.

Neither does Git though. I’m not really sure I follow your point. This is clearly intended as an alternative to submodules. It says so!

I’m not saying it’s an exact copy of git submodules.

First line of the readme:

vdm is an alternative to e.g. Git Submodules for managing arbitrary external dependencies for the same reasons, in a more sane way.

It would be good to see a comparison with the many other reimplementations of submodules.

Git is all about tracking changes over time which is meaningless with binary files.

Utter codswallop. You can see the changes to a PNG over time. Lots of different UIs will even show you diffs for images.

Git can track changes to binary files perfectly well. It might not be great at dealing with conflicts in them but that’s another matter.

The only issue is that binary files tend to be large, and often don’t compress very well with Git’s delta compression. It’s large files that are the issue, not binary files. If you have a 20 kB binary file it’s going to be absolutely fine in Git. Likewise a 10 GB CSV file is not going to be such a good idea.

The main downside is Git downloads all history by default, and so any large files will bloat the download for people cloning your repo forever. It isn’t about binary vs text. It’s just the size that matters.

Gil looks quite interesting, thanks for the link!

Do you actually have any specific, tangible issue with submodules?

Yeah sure. These are few that I can remember off the top of my head. There have been more:

• Submodules don’t work reliably with worktrees. I can’t remember what kind of bugs you run into but you will run into bugs if you mix them up. The official docs even warn you not to.

• When you switch branches or pull you pretty much always have to git submodule update --init --recursive. Wouldn’t it be great if git could do that for you? Turns out it can, via an option called submodule.recurse. However… if you use this you will run into a very bad bug that will seriously break your .git directory.

• If you convert a submodule to a directory or vice versa and then switch between them git will get very confused and you’ll have to do some rm -rfing.

Even in the cases you’re clearly and grossly misusing them

Oh right, so the bugs in Git are my fault. Ok whatever idiot.