That's not how I understood it. Full clones are big but simple — the server just sends all the packfiles. A first shallow clone needs some server work, but that's cachable, OK.
But then on subsequent interactions between a git client that made a shallow clone various time ago and the git server, it's AFAIU actually expensive for the git server to compute the portion this particular client doesn't yet have.
Intuitively, and very hand-wavingly, I suspect things could be improved by:
(1) clients relaxing "exact depth" requests to "give me approximately N days of stuff, over-sending being OK", and server relaxing "minimal traffic" to roughly map time ranges to whole packfiles — CPU/traffic tradeoff.
(2) allowing servers to under-send too (makes (1) tradeoffs easier), by client asking for missing parts right away and/or later — needs on-demand fetch ability to be transparent to user. With "promisor" mechanism in "partial clones" this sounds more realistic?
(3) storing history/trees/blobs in entirely separate packfiles(?) I suspect recent years work on bitmaps & MIDX move in this direction, only less naively?
I'm not saying Git can scale as well as a DB, but I do feel we sat on an effectively frozen Git format & protocol for a ~decade, and are now exploring more of the design space so hope future will be less clear-cut...
And specifically, partial clones remove the hard "fully offline vs. centralized" dichotomy we long clinged to. Assuming you stay online (necessary anyway if you consider HTTP/DB), things that used to be up-front UX decisions can now be matters of perf tuning!
* The most dramatic win is if you had to fetch info from every package's separate repo, like Go did. Then, a central DB/caching proxy can build global indexes, unlocking huge wins, no question. It's like "1+N" issues. However, most examples other than Go in the article talk of a single Git repo already storing a global view (still leaving opportunity for custom indexing and querying).
Totally. She has a fearless approach to learning complex topics (my favourite quote is simply "Computers are knowable", though I couldn't find it — I think she said it on some podcast?) that doesn't shy away from acknowledging ways in which stuff is genuinely hard (e.g. https://jvns.ca/blog/2024/03/22/the-current-branch-in-git/ is among the best usability/learnability dissections I've seen).
Computers are not a kitchen. They are clay, they are Lego, they are jungles of imagination. It's true that our current trajectory devolves their universality to a set of discrete isolated applications == multiplexing a set of appliances on one device.
That's an economic win sure, but it's tragic if we fail to unlock more of their flexibility for "end users"! IMHO that's the biggest unsolved problems of computer science: that it takes so much professional learning to unlock the real potential (and even that fails us programmers much of the time! How frequently do you say "I'll solve it myself" and the time invested is actually worth it? In the words of Steve Krouse we've not quite solved "End-programmer Programming" yet.)
I do want FOSS to follow through and offer live inspectors for everything, but no, I no longer believe users should "learn to code" as the salvation. We're nowhere near it being worth their time, we actually went downhill on that :-( Conversational AI and "vibe using" will play a role, but that's more like "adversarial interoperability", doesn't cover what I mean either.
I want cross-app interoperability to be designed in, as something everyone'd understand users want. I want agency over app state — snapshot, fork, rewind, diff etc. I want files back (https://jenson.org/files/), and more¹. I want things like versioning and collaboration to work cross-app. I want ideas and metaphors we haven't found yet — I mean it when I call it unsolved problem of CS! — that would unlock more flexible workflows for users, with less learning curve. The URL was one such idea - unlocking so much coordination by being able to share place[+state] in any medium.
I want software to be malleable (https://malleable.systems/) in ways meaningful to users. I want all apps to expose their command set for OS-level configurability of input devices & keyboard shortcuts (Steam Input on steroids). I want breakthroughs on separating "business logic" from all the shit we piled, so users can "view source" and intervene on important stuff, like they can in spreadsheets. (I want orders of magnitude smaller/simpler shit too.) I want the equivalent of unix pipes combinatorial freedom² in GUI apps. I want universal metaphors for automation, a future not unlike Yahoo Pipes promised us (https://retool.com/pipes) though I don't know in what shape. I want previewable "vector actions", less like record-macro-and-pray-the-loop-works more like multiple cursor editing. I want more apps to expose UX like PhotoShop layers, where users are more productive manipulating a recipe than they'd be directly manipulating the final result. (https://graphite.art/ looks promising but that's again for visual stuff; we need more universal metaphors for "reactive" editing... I want an spreadsheet-like interface to any directory+Makefile. I want ability to include "formulas" everywhere³.) I want various ideas from Subtext (https://www.subtext-lang.org/retrospective.html).
I want user access to the fruits of 100% reproducibility, including full control of software versions (which are presently reserved to VM/Docker/Nix masters). I want universal visibility into app behavior — what it accessed, what it changed on your computer/the world, everything it logged. Ad blockers actually achieve 2 ways to inspect/intervene: starting from the UI (I don't want to see this), and starting from network behavior (I don't want it to contact this), and both give users meaningful agency!
I'm not sure of the timing (and whether you're sarcastic) but yeah, I found it funny compared to PARC showing Steve Jobs how the Smalltalk environment allowing modifying GUI behavior at run-time let them iterate quickly, sometimes in front of users (https://www.youtube.com/watch?v=uknEhXyZgsg&lc=UgwYCZ7PefOXO...).
I disagree. Assuming it's their own device, set up automated backup, but let them trash the OS. PCs/laptops are (still) pretty much un-brickable at software level.
If they do, re-installing & fishing around the backup will be a learning experience, and the fact you trusted them "this is YOUR device" will be a positive ownership experience that is getting rare nowdays...
* Linux live USBs can be a nice safe intro to such power? Give them 2-3 with differnt-looking distros (even if cosmetic ;-), tell them "try this for a day, if you decide which one you like it you can install it permanently". Hmm, I should try this with my kids!
[Python is great; my comment is only within block-based languages]
For those actively teaching¹, consider Snap! (https://snap.berkeley.edu/) over/after Scratch. It's nearly a superset, similarly "low-floor" but much "higher ceiling" powerful language.
Data structures, control structures/message passing, functional programming... It's really "Scheme in Scratch clothing" under the hood.
In particular, its "build your own blocks" facilities are powerful enough (including macros i.e. custom control structures receiving "body" arguments as unevaluated lambdas) for you to build any scaffolding they need to focus on concepts you want them to learn at this stage.
¹If you don't have much time to sit with them, Scratch may win on "go find tutorials on youtube".
https://criu.org/ (Checkpoint/Restore In Userspace) is a long-running project (i remember the name over a decade ago) worth checking... Ooh, looks like they made progress in conveniently connecting it to containers.
Conversely, when you already collaborate with people in Dropbox, mainly via files, having real time co-editable docs under same folder with same sharing was nice, esp. for people who never remember where they put stuff :-)
Integration was not perfect, but it does create a json .paper file containing a url. But at least it makes you aware the doc exists every time you look at the folder.
Alas, with Paper desktop & mobile apps being deprecated, that's increasingly useless :-( Will the main app at least take over the ability to [double-]click these .paper docs to open them in a browser?
But then on subsequent interactions between a git client that made a shallow clone various time ago and the git server, it's AFAIU actually expensive for the git server to compute the portion this particular client doesn't yet have.
Intuitively, and very hand-wavingly, I suspect things could be improved by:
(1) clients relaxing "exact depth" requests to "give me approximately N days of stuff, over-sending being OK", and server relaxing "minimal traffic" to roughly map time ranges to whole packfiles — CPU/traffic tradeoff. (2) allowing servers to under-send too (makes (1) tradeoffs easier), by client asking for missing parts right away and/or later — needs on-demand fetch ability to be transparent to user. With "promisor" mechanism in "partial clones" this sounds more realistic? (3) storing history/trees/blobs in entirely separate packfiles(?) I suspect recent years work on bitmaps & MIDX move in this direction, only less naively?
I'm not saying Git can scale as well as a DB, but I do feel we sat on an effectively frozen Git format & protocol for a ~decade, and are now exploring more of the design space so hope future will be less clear-cut...
And specifically, partial clones remove the hard "fully offline vs. centralized" dichotomy we long clinged to. Assuming you stay online (necessary anyway if you consider HTTP/DB), things that used to be up-front UX decisions can now be matters of perf tuning!
* The most dramatic win is if you had to fetch info from every package's separate repo, like Go did. Then, a central DB/caching proxy can build global indexes, unlocking huge wins, no question. It's like "1+N" issues. However, most examples other than Go in the article talk of a single Git repo already storing a global view (still leaving opportunity for custom indexing and querying).
reply