Gitlet: Git implemented in JavaScript
gitlet.maryrosecook.com
gitlet.maryrosecook.com
https://github.com/libgit2/libgit2/blob/master/src/rebase.c may be helpful and (hopefully) readable.
1. http://maryrosecook.com/blog/post/git-in-six-hundred-words
'cos clearly whatever he was doing was acceptable up till that point.
where did my changes go?
cd commadir
git init
echo "dog" >> dog.txt
git add .
git commit -m one
echo "dog" >> dog.txt
git add .
git commit -m two
echo "dog" >> dog.txt
git log
git checkout dog.txt
cat dog.txt
how many dogs in dog.txt?
I can certainly understand the danger/confusion there, though. Using checkout on a file reverts the file to a committed state. But the grandparent was referring to checking out a branch, not a file, which is safe.
has the same behaviour. does it not? I left out the asterisk as I was working from memory.
Why would you think otherwise?
it's a learning curve alright.
Ah, missed that -- and I concur with the other commenter that this is bad UI.
However, I don't think this qualifies as particularly dangerous or surprising behavior. You're explicitly giving a file name after all -- you had better read up on what the command does if you're doing that. ("rm X" is pretty good precedent.)
Does "checkout -- some-file" not add an entry to the reflog?
(Which, btw, is one of the most important and useful commands ever in the history of VCS.)
git checkout <commit-hash> <filename>
working copy of filename now gone if not committed.
update, this is what i meant:
"git checkout * "
"git checkout <commit-hash> * "
"git checkout <branch> * "
each have the same warningless wipeout of uncommitted changes.
http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...
Not exactly a 'how it works' article, more how it can work really well
> you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.
Kickstarter: https://www.kickstarter.com/projects/creationix/js-git
edit: after some research turns out the link underline styling is a Safari thing. My point stands, though, the typography is wonderful.
When the source itself is available, why not just read the code? I understand using articles and documentation to get the high to mid level view, but why not go to the real source of truth if it's available?
Peter Seibel wrote a great post on code reading, which hits on a similar point: http://www.gigamonkeys.com/code-reading/
It's like reading a math paper where they define all the variables they use first before even getting to the main ideas. It's more rigorous, but not necessarily the most straightforward way to convey something.
Also, you don't necessarily always care that something is a struct or a union or that it's implemented as a custom variant of a B+tree that does xyz or that there's this quirk on Solaris that causes filenames to be written on disk backwards or something.
Also, the git source isn't the easiest code to follow.
Warning: the file format has changed slightly.
I wrote Gitlet to explain how Git works. I didn't write it to be used. It would be unwise to use Gitlet to version control your projects.
Any volunteers for making an operating system kernel? Or has that been done already?
[1] https://github.com/creationix/js-git
It's using emscripten, not handwritten JS, though.
It was really impressive to see UE4 running at ~7 fps on an old ThinkPad (without discrete GPU) in pure software.
It looks like the demo lived at the time at https://www.unrealengine.com/html5 - and the site doesn't seem to work through Wayback Machine.
bbl
Well, there's a PC emulator, http://bellard.org/jslinux/tech.html
I think you just did that.