3 ms·

I think there's a bit of that in git in particular. The irony is that if you think of git in terms of deltas, with branches just being tags to commits, and "gi

by rtpg 10y ago

I think there's a bit of that in git in particular. The irony is that if you think of git in terms of deltas, with branches just being tags to commits, and "git commit" actually being "git commit + move branch", then a lot of stuff is easier to reason about. Like, if you get the notion of working tree, staging area, commits, and branches on a deep-ish level, things get easier. Things can still be hard, but there's a lot less "does running this cause everything to disappear???" I think it would be possible to make this awesome page even more awesome with a little "annotated version" that gives the details of what you're actually doing.

dfsegoat 10y ago
> and "git commit" actually being "git commit + move branch" Can you elaborate on that a little more? I liked where it was going -- because being able to explain how git works to someone coming from SVN has been an ongoing problem for me.
- _ikke_ 10y ago
  In git, branches are pointers to commits (branches are a specific kind of refs or references). When you commit, git creates a new commit object, links it to the last commit on that branch, and then points that branch to the new commit. This way, you get a chain of commits, each pointing to the previous commit, and and branch references pointing to the last commit of each branch.
- chaosemer 10y ago
  Simplifying things a bit, git is what you did before you learned about using version control. That's right, it's just the old copy/paste the entire project folder for each revision and give it a name like "Project v1", "Project v2", etc. Branches and tags are then just symlinks to a specific folder. In this world, when you commit, you're doing two things: 1. Creating a new top level folder, e.g. "Project v42". 2. Updating the branch symlink you are on to point to that new folder. I'm actually not simplifying things that much here, the main git addition is that each folder (revision) also has a list of previous folders (revisions) and that the folders (revisions) are not named sequentially, they are named based on a hash of their contents.

by rtpg 10y ago

dfsegoat 10y ago

> and "git commit" actually being "git commit + move branch" Can you elaborate on that a little more? I liked where it was going -- because being able to explain how git works to someone coming from SVN has been an ongoing problem for me.

_ikke_ 10y ago
In git, branches are pointers to commits (branches are a specific kind of refs or references). When you commit, git creates a new commit object, links it to the last commit on that branch, and then points that branch to the new commit. This way, you get a chain of commits, each pointing to the previous commit, and and branch references pointing to the last commit of each branch.
chaosemer 10y ago
Simplifying things a bit, git is what you did before you learned about using version control. That's right, it's just the old copy/paste the entire project folder for each revision and give it a name like "Project v1", "Project v2", etc. Branches and tags are then just symlinks to a specific folder. In this world, when you commit, you're doing two things: 1. Creating a new top level folder, e.g. "Project v42". 2. Updating the branch symlink you are on to point to that new folder. I'm actually not simplifying things that much here, the main git addition is that each folder (revision) also has a list of previous folders (revisions) and that the folders (revisions) are not named sequentially, they are named based on a hash of their contents.