Great presentation!
I created something similar — a step-by-step Git implementation that is designed for teaching Git internals:
Gitlet.js – Git implemented in 1k lines of JavaScript (2015)
61–70 of 78 posts
Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)
#62Earlier quoted context omitted.
> ‘git restore’ is the way to do this in the current version of git. No, that’s incorrect. `git checkout` is the way to do this in the current version of Git. The current version of Git allows you to use `git restore`, but the documentation says this about it: > THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. Until that warning goes away in a future version of Git, `git checkout` is the way to do this.
Fair point, I had honestly never read the docs page on restore. But , I still have to disagree. They may not have landed on the final shape of the API, but they are clearly encouraging people to use restore for this purpose. There is no ‘warning’ message in the CLI. In fact the opposite, the help text in every ‘git status’ message explicitly states to use ‘restore’ for the case of resetting the changes of a single fi…
> the help text in every ‘git status’ message explicitly states to use ‘restore’
Good point. This makes no sense. There should either be a warning in the documentation and `git status` should not recommend it, or there should not be a warning in the documentation and `git status` should recommend it. It’s either ready for use or not, it shouldn’t be inconsistent about it.
I agree it’s a positive change, but the current state is ambiguous when it shouldn’t be.
You don’t need the “weird -- flag” in most cases, by the way, it’s not Git to blame for that, and it’s the same for both checkout and restore. The `--` is the standard POSIX way to distinguish between options and filenames. If there’s no ambiguity (e.g. `git checkout .`) then you can skip it. You only need it if the pathspec could be interpreted as an option.
Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)
#63Reading stuff like this makes me lose all hope to ever really understand (and being able to tame) git:
> Under the covers, the pull command runs git merge FETCH_HEAD. This reads FETCH_HEAD, which shows that the master branch on the beta repository was the most recently fetched branch. It gets the commit object that alpha’s record of beta’s master is pointing at. This is the second commit. The master branch on alpha is pointing at the first commit, which is the ancestor of the second commit.
Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)
#64So, I'm going to put that out there, but I really wish I could read security-sensitive code like this. TLS implementations, cryptographic implementations, etc. It would be really amazing if there was a way for Github to automatically display code like this by extracting comments out. In general I think it's an amazing way of learning, I remember reading the gobyexample.com website and writing the same thing for go as…
Here is some JWT minting and parsing you can run in the browser https://observablehq.com/@tomlarkworthy/firebase-admin ported from MIT licensed firebase-admin Github repo.
Oauth 2.0 clients https://observablehq.com/@tomlarkworthy/oauth-examples
This is a WIP but its a full on Identity Provider implemented the browser it a literate programming env! https://observablehq.com/@endpointservices/auth
Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)
#65Earlier quoted context omitted.
> Not only is it more semantic, it reduces the complexity of ‘git checkout’ which is a common complaint. It doesn’t since the feature can’t be removed from git checkout for BC reasons.
I don't see why it couldn't be removed from a future release after a period of deprecation.
Because there’s a million aliases out there which alias « git checkout —- . » to something sensible and there is no real justification for breaking them: checkout can trivially delegate to restore.
Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)
#66So, I'm going to put that out there, but I really wish I could read security-sensitive code like this. TLS implementations, cryptographic implementations, etc. It would be really amazing if there was a way for Github to automatically display code like this by extracting comments out. In general I think it's an amazing way of learning, I remember reading the gobyexample.com website and writing the same thing for go as…
As @chungy says in a sibling comment, this is what's known as a literate program. It never really took off, and I suspect it's partially because doing it well means you'll be writing a lot more text than you'd typically see in a program's comments. See http://www.literateprogramming.com/ for more information and examples.
Huh. I actually write my code in this style. Perhaps not quite as detailed, but with the same idea in mind.
I wish code like this was more common. Over and over, I've heard fellow programmers reply with something along the lines of "well it should be obvious what it does! just look at the name and implementation - all you need is right there", when it was suggested that they add documentation to their implementations. What never seems to quite get across fully is that, yes, the code is all there, and it may even be clean and fairly readable, but the inherent complexity is such that only programmers experienced in subject X will ever have a chance of actually understanding it.
"So, what? If it's that complex, then maybe only programmers who are that experienced should attempt to read and/or contribute to it"* is another sentiment I've seen expressed. Of course, this misses the logic that, in order for such programmers to exist, they have to learn from somewhere, and start from something.
And how will we ever have programmers experienced in that subject
Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)
#67So, I'm going to put that out there, but I really wish I could read security-sensitive code like this. TLS implementations, cryptographic implementations, etc. It would be really amazing if there was a way for Github to automatically display code like this by extracting comments out. In general I think it's an amazing way of learning, I remember reading the gobyexample.com website and writing the same thing for go as…
Comments are good, this particular instance, not so much.
This description spends a lot of time stating the blindingly obvious, eg:
if (addedFiles.length === 0) {
// Abort if no files matched path.
throw new Error(files.pathFromRepoRoot(path) + " did not match any files");
// If --bare was passed, write to the Git config indicating that the repository is bare.
// If --bare was not passed, write to the Git config saying the repository is not bare.
config: config.objToStr({ core: { "": { bare: opts.bare === true }}}),
I feel that explaining TLS and similar in this manner would be completely unhelpful. Check out this document, for instance, specifically the "Algorithm for crypt" part:
https://www.akkadia.org/drepper/SHA-crypt.txt
Very well explained. But try and tell me what's the purpose and why those specific steps, which look increasingly bizarre as you delve in, and whether deviating from any given step would be acceptable or not (ignoring matters of compatibility)
Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)
#68Earlier quoted context omitted.
As @chungy says in a sibling comment, this is what's known as a literate program. It never really took off, and I suspect it's partially because doing it well means you'll be writing a lot more text than you'd typically see in a program's comments. See http://www.literateprogramming.com/ for more information and examples.
Huh. I actually write my code in this style. Perhaps not quite as detailed, but with the same idea in mind. I wish code like this was more common. Over and over, I've heard fellow programmers reply with something along the lines of "well it should be obvious what it does! just look at the name and implementation - all you need is right there", when it was suggested that they add documentation to their implementations…
Yes, they have to start somewhere. That somewhere is reading and working with the code they want to read slowly.
Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)
#69I'd strongly suggest looking at https://github.com/isomorphic-git/isomorphic-git
It's a newer Git implementation but it has loads of features and it's easier to read than most. An excellent project.
Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)
#70Earlier quoted context omitted.
As @chungy says in a sibling comment, this is what's known as a literate program. It never really took off, and I suspect it's partially because doing it well means you'll be writing a lot more text than you'd typically see in a program's comments. See http://www.literateprogramming.com/ for more information and examples.
Try and read the source to Metafont. It's a scattered morass with blocks of code broken out from it's point of usage for expository purposes.
Or the OG TeX for that matter. Knuth writes his code in WEB (his own literate programming language based on Pascal)