3 ms·

The biggest leaking abstraction of git IMO, are commits: they equate a set of changes with the state of the repo after said changes. So if there are multiple co

by meuk 8y ago

The biggest leaking abstraction of git IMO, are commits: they equate a set of changes with the state of the repo after said changes. So if there are multiple commits, reverting a commit is ambiguous. Does it revert the state of the repository to the state before the commit, or does it revert the changes in the commit? There are a couple more flaws. The commandline is not very consistent, and the complete model is way too complicated IMHO. I can work with it now, but it took me a long time to grasp all of the concepts that I need - without feeling the need for distibuted version control. About that: It's kind of ironic that git is hailed for being distributed, but everyone just uses github, a centralized system.

cesarb 8y ago
Just to be pedantic, a commit is actually "the state of the repo after said changes" plus "the commit(s) before said changes" (which allows one to recover the "set of changes" by comparing the before/after states).
- meuk 8y ago
  I don't think that's true. At least, not if you revert something - it reverts only the changes introduced in that commit. (That there is confusion - or even discussion possible - is exactly my point: the abstraction is leaky at worst, and confusing at best). Edit: You're right, but my point was that the revert command treats a commit like a set of changes, not like the state of of a repo (since you can't revert the state of a repo, but you can revert changes).
  - cesarb 8y ago
    See for yourself: do a "git cat-file commit HEAD" on any repository. The "tree" line is the current state, the "parent" line(s) are the preceding commit(s). That command shows everything git has recorded for any commit (you can similarly use "git ls-tree <sha1>" to show everything git has recorded for any tree, or "git cat-file blob <sha1>" to show the contents of a file from the tree).
    - meuk 8y ago
      You're right from a technical perspective. What I meant that as an abstraction, it serves a double purpose (it represents both a node and an edge in the DAG, and it depends on the command that you use which interpretation is right). If you checkout a commit, the commit represents the state of the repository. If you revert a commit, the commit represents a set of changes.

by meuk 8y ago

cesarb 8y ago

Just to be pedantic, a commit is actually "the state of the repo after said changes" plus "the commit(s) before said changes" (which allows one to recover the "set of changes" by comparing the before/after states).

meuk 8y ago
I don't think that's true. At least, not if you revert something - it reverts only the changes introduced in that commit. (That there is confusion - or even discussion possible - is exactly my point: the abstraction is leaky at worst, and confusing at best). Edit: You're right, but my point was that the revert command treats a commit like a set of changes, not like the state of of a repo (since you can't revert the state of a repo, but you can revert changes).
- cesarb 8y ago
  See for yourself: do a "git cat-file commit HEAD" on any repository. The "tree" line is the current state, the "parent" line(s) are the preceding commit(s). That command shows everything git has recorded for any commit (you can similarly use "git ls-tree <sha1>" to show everything git has recorded for any tree, or "git cat-file blob <sha1>" to show the contents of a file from the tree).
  - meuk 8y ago
    You're right from a technical perspective. What I meant that as an abstraction, it serves a double purpose (it represents both a node and an edge in the DAG, and it depends on the command that you use which interpretation is right). If you checkout a commit, the commit represents the state of the repository. If you revert a commit, the commit represents a set of changes.