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

Post by bollu » Tue, Apr 13, 2021, 5:51 AM UTC

jacobolus wrote: post #42

pmiller2 wrote: post #39

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

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

Post by ptbrowne » Tue, Apr 13, 2021, 6:16 AM UTC

momothereal wrote: post #8

In the 'real' Git, one of the functions I use frequently is `git checkout -- .`, which discards any unstaged changes. Looking at Gitlet's implementation, it wouldn't handle that well as `checkout` can only take a ref. So I guess I'm wondering what the real `git checkout -- .` actually does behind the scenes?

Post by paublyrne » Tue, Apr 13, 2021, 6:42 AM UTC

masklinn wrote: post #32

40four wrote: 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…

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

Post by Stratoscope » Tue, Apr 13, 2021, 6:46 AM UTC

asxd wrote: post #20

billconan wrote: post #6

Earlier quoted context omitted.

it's not that simple. git is a snapshot, i.e. it saves an entire file. How to recover changed lines from it efficiently? And How to do it for the entire history? Basically, I want to understand this code https://github.com/git/git/blob/master/blame.c

I was replying to another comment that has since been deleted. It said something roughly along the lines of git blame being a contentious and passive aggressive command. I totally agree the technical implementation would be cool to study :)

Post by platinumrad » Tue, Apr 13, 2021, 6:48 AM UTC

baby wrote: post #52

pmiller2 wrote: post #39

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

I think that this is something else, it's a simple difference but having the code on the size changes everything for me.