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.
the occasional submodule hiccup because it was misused as a replacement for a package manager when it really shouldn’t
I don’t see why using submodules as a package manager should excuse their endless bugs. I think you just have low standards.
The UX flaws of Git are very obvious IMO. Even the naming is terrible (“index”? What was wrong with “draft”?).
And it’s definitely not a solved problem. Aside from the obvious UX disaster, Git has some big issues:
I think the biggest issue is dealing with very large code bases, like the code for a mid-large size company. You either go with a monorepo and deal with slowness, Windows-only optimisations and bare minimum partial checkout support.
Or you go with submodules and then you have even bigger problems. Honestly I’m not sure there’s really an answer for this with Git currently.
It’s not hard to imagine how this might work better. For instance if Git repos were relocatable, so trees were relative to some directory, then submodules could be added to a repo natively just by adding the commits and specifying the relative location. (Git subtree almost does this but again it’s a tacked on third party solution which doesn’t integrate well, like LFS.)
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 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-toolsit 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.