Live data from Hacker News

Gitlet.js – Git implemented in 1k lines of JavaScript (2015)

gitlet.maryrosecook.com

41–50 of 78 posts

Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)

#41
post #35

Earlier 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.

It does, because it sounded like he was concerned with the complexity of explaining the broadness of uses for git checkout. Now we can treat git restore like it is a separate thing.

This is a better way to say it and what a I meant thanks.

Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)

#42
post #36

So, 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.

The particular method of turning javascript comments into a "literate" source view, used in the link under discussion here, comes from Jeremy Ashkenas circa 2009, e.g.:

https://underscorejs.org/docs/underscore-esm.html

https://coffeescript.org/annotated-source/lexer.html

https://backbonejs.org/docs/backbone.html

Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)

#43
post #22

Earlier quoted context omitted.

This is correct, ‘git restore’ is the way to do this in the current version of git. ‘checkout —-‘ still works, but the ‘help’ text in ‘git status’ now recommends using ‘restore’. Not only is it more semantic, it reduces the complexity of ‘git checkout’ which is a common complaint. Really, It doesn’t make much sense to tack on some random ’--‘ flag on ‘checkout’ for that functionality. ‘restore’ is clear and describes…

> ‘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 file, where it used to say use ‘checkout —-‘.

Yeah I’m used to using checkout —- like the rest of us, and sure we can all still do it if we want. But I would never recommend ‘checkout —- filename‘ to anyone in 2021. It doesn’t make any sense that that would be how you do that. It’s confusing trying to explain it to someone.

“Yeah I know you usually use this to completely change branches, or go to a particular commit hash. But if you use this weird ‘—-‘ flag & a file name, it does a mini ‘reset’ on that one file”

Why would you use some random flag on a command (checkout) that is typically used for a totally different use case? If anything, this should be a flag on ‘reset’.

I’m not a git ’complexity hater’, but it’s a perfect example of why a lot of people complain about git.

Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)

#44

this is cool! but I'm curious to see a git blame implementation.

You mean the most conflict driven and passive aggressive feature in any programming tooling?

Please don't take HN threads on flamewar tangents. That's what we're trying to avoid here.

https://news.ycombinator.com/newsguidelines.html

Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)

#46

Earlier quoted context omitted.

You mean the most conflict driven and passive aggressive feature in any programming tooling?

That's Linus for you, I guess? I dunno, I always found `git blame` really funny yet at the same time, I empathize with those who are a little taken aback by it (including... what's the company's name who makes IDEs who calls it "annotate"... ?). I largely love it because most of the time when I `blame`, that's exactly what I want to do. I don't need software to give me a nicer verb so I can pretend that's not what I'…

Git can also be an offensive word just like blame. It just depends on what attitude people have towards the context. I am not offended by git, blame, master and slave and I think it would be best if people who are offended just change their attitude towards the context

Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)

#47
The format is nice, but I can't help but feel it'd be much easier for a human to parse as just normal TS with docstrings for flavor. For some of the more advanced functions, it's all but impossible to actually figure out what the input and return types are -- one must parse the english to find the references to "(see the module description for the format)", then try to figure out what that means, then go there, then repeat, until primitives are reached. Compare to TS where the return type is either right there in the code, or I can at least hover over the function to see a preview or Cmd+Click to get to the type definition itself.

Not to mention the difficulty of manually keeping the english type descriptions in concert with the actual code -- some things computers are much better at than humans, verifying types is one of them.

All that said, the flavor text is well written and I'm glad the author took the time to include it!

Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)

#48
post #37
post #36

So, 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…

It's a very old idea. Donald Knuth implemented it with both Pascal and C to promote an idea of "literate programming" -- you'd literally just write prose sprinkled with little bits of programming. On compilation, you can choose to compile either the documentation or program.

For an example, the PBRT book is great.

Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)

#49
post #37
post #36

So, 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…

It's a very old idea. Donald Knuth implemented it with both Pascal and C to promote an idea of "literate programming" -- you'd literally just write prose sprinkled with little bits of programming. On compilation, you can choose to compile either the documentation or program.

The deep learning library fastai uses this. Their source code is also their documentation. They use something called "nbdev" to accomplish this. And I have also seen other projects both related and unrelated to deep learning adopt it. This idea stems from Knuth.

Re: Gitlet.js – Git implemented in 1k lines of JavaScript (2015)

#50
post #36

So, 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.

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.
Post reply on HN