I can't seem to find the rebase code? I've always wondered how that part works. Great work otherwise! I've already taken a look at the three way merger code.
> Sometimes, I can only understand something by implementing it. So, I wrote Gitlet, my own version of Git. I pored over tutorials. I read articles about internals. I tried to understand how API commands work by reading the docs, then gave up and ran hundreds of experiments on repositories and rummaged throught the .git directory to figure out the results.
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?
I find reading the source of things can be incredibly helpful in some cases, but when I want to really grok something, I need to write code myself. When I'm just reading code it's easy to trick myself into thinking I understand something, but it's much harder to do that if I have to make a piece of code work correctly.
I was referring more to the "ran hundreds of experiments" than the "understanding by implementing." I agree wholeheartedly that actually making something reveals far more about a problem/solution than would simply reading about it.
It's just a different approach - sometimes understanding top-down is easier than bottom-up. The git code is pretty clean and simple, but pedagogically speaking it's not super easy to get an understanding of everything without reading most of it.
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.
Not to be rude, but I'm baffled why a professional programmer could be "wary" of using a VCS. Or is it just git in particular? (More understandable, there's a learning curve, but nearly every major project is using it. Git's proven itself.)
i once took a leadership position at a small company that had a longtime contractor building one of their core web products out of foxpro. he refused to use any VCS, proclaiming that "version control is for the weak". needless to say, he didn't last very long.
There's no real opinion being given here. That would be like suggesting a general contractor on a new home was fired for difference of opinion, when the reason was he just didn't have insurance.
That isn't "git checkout <branch>", it is "git checkout <file>"
If you try checking out another branch while you have uncommitted changes, git will tell you to commit or stash your changes before changing branch.
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.
Except that `checkout` makes the working copy match the target branch, which destroys the pending changes in the working copy, if a path is specified. It's the same as `revert` in other version control systems.
> Not to be rude, but I'm baffled why a professional programmer could be "wary" of using a VCS. Or is it just git in particular? (More understandable, there's a learning curve, but nearly every major project is using it. Git's proven itself.)
(I'm not sure "if a path is specified" was actually part of the comment when I responded, but I'll grant that...)
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.)
of course you are correct. i am sorry. i was doing it from memory. you can leave out the commit-hash too, to get the same effect. not at a computer now but i think i remember "git checkout <commit-hash> * " being extra fun.
update, this is what i meant:
"git checkout * "
"git checkout <commit-hash> * "
"git checkout <branch> * "
each have the same warningless wipeout of uncommitted changes.
I think it's git in particular. Git can seem like it has more complexity than is necessary for a version control solution for some arbitrary "simple" project.
> 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.
It would be interesting to see this baked into a browser-based text editor. Make it fully client side and you can potentially save the git history in localstorage and use it as an offline web app. I wonder if there are any git servers that support websockets...
Can't tell if you mean overwriting after every keystroke (if so, no history); or saving a "fresh copy" after each keystroke (history, but terribly inefficient - localStorage has space limitations); or saving a series of diffs (how far do you have to go down that path before you realise you should have just used git?)
I've asked GitHub to enable CORS for their https git endpoints, and I'm not the first. Email them at support@github.com if you can think of some cool stuff to do with that enabled.
This is a collossal effort and a huge community service. Thank you for being so thorough in documenting your work. Even if others don't directly use your code, you have given the world a great template to understand and implement git!
git is a tool that have to be introduced to as many as possible, even non-developers. In essence git is a fundamental part of the future global world collaboration. One can't overestimate the gits value.
69 comments
[ 2.9 ms ] story [ 139 ms ] threadhttps://github.com/libgit2/libgit2/blob/master/src/rebase.c may be helpful and (hopefully) readable.
Any volunteers for making an operating system kernel? Or has that been done already?
[1] https://github.com/creationix/js-git
[2] https://www.kickstarter.com/projects/creationix/js-git
[3] https://www.bountysource.com/teams/js-git/fundraiser
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
Kickstarter: https://www.kickstarter.com/projects/creationix/js-git
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.
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.
https://news.ycombinator.com/item?id=8934475
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.
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.
I think you just did that.
edit: after some research turns out the link underline styling is a Safari thing. My point stands, though, the typography is wonderful.