I would guess that for at least 90% of the repos I clone, I just want to install something. Even for the rest, I might hack on the code but seldom look into the history. If I do then I could do a `git fetch` at that point and save the bandwidth and disk space the rest of the time.
Its not the default because that'd be counter-productive to developers who use git with larger repositories, which is how git started life in the first place - your clone depth would be entirely useless for Linux kernel developers, for example, if it were default ..
What is worse is that for about half a year or so, I now have to authenticate my ed25519-sk key with my Yubikey thrice (!) when using LFS. On every push.
Git is industry standard, because for what it give you it's a remarkably robust and simple program to use. We're all vaguely aware that the internals are complex, but the UX is clean and usable enough that the complexity usually doesn't leak out.
But the day this breaks down and I have to deal with bloom filters, packfiles, maintaining the git garbage collector or rerere cleanup, is the day I switch our codebase to a centralized VCS.
This stuff is cool to learn about; but it's 5 layers removed from anything I want to be thinking about in my day to day work.
I've always wanted to see a book that describes git for the common man and gives them tons of examples for how to use it to do productive things.
Even for a small office, git can be immensely useful. Entire production line workflows can be implemented with git .. if only folks would learn to use it productively.
Its not just for development. Writers can use it productively. Accountants too.
It always kind of irks me that Git hasn't just been folded into the OS front-end UI by any of the OS vendors .. it'd be so revolutionary to give common folks an easy way to manage the timeline/history of their computer use using git.
I never faced git performance issues when working with code. Guess my repos weren't bit. But when I tried to use git as a versioned database of changes in my pet project, I learned a lot about indexes, compacting, etc. Article covers a lot and is very helpful!
Similarly, if not performance-focused, I can wholeheartedly recommend Building Git[0], which walks you through building your own git clone in Ruby (although the language is immaterial).
Surprise, surprise, another piece of LLM-generated slop on the front page of HN.
From chapter 1:
> When Git slows down, engineers adapt in bad ways. They stop asking questions the history could answer. They batch work to avoid sync cost. They keep messy branches alive longer, postpone cleanup, and treat the repository like something slightly dangerous.
> Once machines start producing code at machine cadence, the model from this book does not break. What changes is the pace: more branches, more commits, more automation, and more surrounding metadata. The traffic gets louder, and the features that keep Git legible under pressure move from "nice to have" to "essential."
> These stop looking like side optimizations. They are what keep machine-scale Git traffic usable.
So nice to see this get picked up, and honestly surprised to see the interest in what I think of as an extremely esoteric area. Few things:
- Just released an Edition 1.1 that fixed some small errors, amended a few chapters content, and removed some general bluster. I'm going to try and, well, version these.
- New things are coming to Git, and I suspect I'll be talking about Git Futures or A Post-Git World soon enough.
- I'll have a couple more highly practical chapters coming soon, focused on pragmatic organizational adoption, e.g., on wrapping the git CLI to best practices
Git's data structure is shockingly simple. Here's an article with diagrams on the four basic data types. Also shows why "HEAD" is different from a "commit".
It annoys me greatly that the megacorps have all these fancy devtools that we plebs have no hope of touching. One example being Metas Sapling, which afaik is their way of making git-compatible vcs perform decently well at their scale. Sure it is nominally open-source, but the readme has enough notes like "Not yet supported publicly, OSS is buildable for unsupported experimentation." to dissuade any casual users. And afaik the others have their own things, mostly even less public.
19 comments
[ 4.0 ms ] story [ 41.0 ms ] threadand also git
which makes more sense i guess
Why isn't
the default?I would guess that for at least 90% of the repos I clone, I just want to install something. Even for the rest, I might hack on the code but seldom look into the history. If I do then I could do a `git fetch` at that point and save the bandwidth and disk space the rest of the time.
Seemingly seconds on every remote-touching command, even on a very small repo.
But the day this breaks down and I have to deal with bloom filters, packfiles, maintaining the git garbage collector or rerere cleanup, is the day I switch our codebase to a centralized VCS.
This stuff is cool to learn about; but it's 5 layers removed from anything I want to be thinking about in my day to day work.
Even for a small office, git can be immensely useful. Entire production line workflows can be implemented with git .. if only folks would learn to use it productively.
Its not just for development. Writers can use it productively. Accountants too.
It always kind of irks me that Git hasn't just been folded into the OS front-end UI by any of the OS vendors .. it'd be so revolutionary to give common folks an easy way to manage the timeline/history of their computer use using git.
[0]: https://shop.jcoglan.com/building-git/
From chapter 1:
> When Git slows down, engineers adapt in bad ways. They stop asking questions the history could answer. They batch work to avoid sync cost. They keep messy branches alive longer, postpone cleanup, and treat the repository like something slightly dangerous.
From https://gitperf.com/epilogue.html
> Once machines start producing code at machine cadence, the model from this book does not break. What changes is the pace: more branches, more commits, more automation, and more surrounding metadata. The traffic gets louder, and the features that keep Git legible under pressure move from "nice to have" to "essential."
> These stop looking like side optimizations. They are what keep machine-scale Git traffic usable.
- Just released an Edition 1.1 that fixed some small errors, amended a few chapters content, and removed some general bluster. I'm going to try and, well, version these.
- New things are coming to Git, and I suspect I'll be talking about Git Futures or A Post-Git World soon enough.
- There's now a free PDF, https://gitperf.com/pdf.html
- I'll have a couple more highly practical chapters coming soon, focused on pragmatic organizational adoption, e.g., on wrapping the git CLI to best practices
https://eagain.net/articles/git-for-computer-scientists/
https://github.com/facebook/sapling