25 ms·

I think the disconnect is that the "first principles" that you can derive from are implementation details; in other words, git makes the most sense if you embra

by saghm 3y ago

I think the disconnect is that the "first principles" that you can derive from are implementation details; in other words, git makes the most sense if you embrace the inherent leakiness of the abstraction. > Perhaps others don't conceive of Git as a datastructure The problem is that git doesn't really look much like a datastructure at first glance; it's ostensibly a shell command that you invoke, which makes people look at it in terms of inputs and outputs rather than spending time learning the details of all of the parts that aren't obviously in plain sight. > A branch is a reference is a pointer to the latest commit in a series. Creating a new commit adds to the top and updates the pointer. I think this is a pretty good demonstration of the issue I'm talking about; I've talked to engineers who totally understand git's underlying model but still are incredibly resistant to this definition of a branch, even though it's the accurate one. The idea of a branch conceptually being the entire chain of commits from the most recent one to the initial one is so pervasive that even the term "branch" heavily implies it (when arguably the more accurate analogy would be to call them "leaves"). When the definition of one of the most fundamental concepts defies people's common intuition, the finer details of advanced operations on them like rebasing don't have a chance of being widely understood. Git's failing isn't that it's complex, it's that the only effective logical unit to think about the system is the entire thing, and that lack of abstraction is the alien model to the way we're encouraged to think of things as programmers.

brabel 3y ago
> arguably the more accurate analogy would be to call them "leaves" I don't think so. Branches are the more accurate analogy because two branches can have many commits on top of each of their common, parent commit - so branches grow as tree branches do, not leaves.
- Shish2k 3y ago
  > so branches grow as tree branches do, not leaves That’s exactly the mistake though - branches (the implementation detail) don’t grow. Branches - under the hood - are “one pointer to one commit”, and they are always the same size. The suggestion to call the implementation “leaves” is because you get a pointer to one commit at the end of the branch, and you can then follow that branch backwards (via the linked-list of parent-commits) until you reach the trunk. But the “branch” is never actually stored anywhere, it is only implied by its ends.
  - brabel 3y ago
    That makes no sense. Different branches always have a common parent commit which is the "branching point". When you update the branch to point to a new commit, your branch is growing apart from the other. The branch analogy makes much more sense.
Izkata 3y ago
I've shown coworkers "git log --graph --oneline --decorate --all -50" many times and always have them start with it (and even use it throughout stepping them through something) to try and show that structure as we go. I think it helps a bit, but their IDEs go to great lengths to keep them out of the command line, so they're never completely sure what happened when it does something odd to their repo.
- formerly_proven 3y ago
  idk I clicked something and then there was an error so I deleted the project and started over
- brabel 3y ago
  > but their IDEs go to great lengths to keep them out of the command line Their IDEs can show them the graph you're talking about in a much richer form, lets them navigate through it, check what each commit did, who did it, and even change the graph (as everything in Git is changeable) by removing/rephrasing commits for example. I don't see how using the terminal actually helps anyone understand git, quite the opposite.
  - Izkata 3y ago
    From what I've seen, they don't have that functionality. But my favorite is that it has a "sync" button for when a local and remote branch diverge due to a rebase, that doesn't tell you what it's going to do. The one time I saw it in use, it rebased new commits from master onto their branch.
    - brabel 3y ago
      IntelliJ: https://www.jetbrains.com/help/idea/investigate-changes.html https://www.jetbrains.com/help/idea/investigate-changes.html VSCode: https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph https://marketplace.visualstudio.com/items?itemName=mhutchie... or https://github.com/gitkraken/vscode-gitlens#commit-graph- https://github.com/gitkraken/vscode-gitlens#commit-graph- SourceTree: https://confluence.atlassian.com/sourcetreekb/viewing-log-history-of-a-repository-785615840.html https://confluence.atlassian.com/sourcetreekb/viewing-log-hi...
rcxdude 3y ago
> I think the disconnect is that the "first principles" that you can derive from are implementation details; in other words, git makes the most sense if you embrace the inherent leakiness of the abstraction. Of the things mentioned in that comment, only SHA1 is really an implementation detail. The rest, especially how commits and branches relate to each other, is basically the core model of using git. The only thing I'd really adjust in that statement is condensing down the description of trees to "commits are a snapshot of the repository" (as opposed to a diff, which a lot of people seem to think commits are despite it being a niche model in VCS design). (To give an idea, I'd condense SVN's model down to similar terms: commits are a snapshot of the repository given a revision number, and branches are copies of the folder structure, or parts thereof, conventionally under branch/)
- avgcorrection 3y ago
  > The only thing I'd really adjust in that statement is condensing down the description of trees to "commits are a snapshot of the repository" (as opposed to a diff, which a lot of people seem to think commits are despite it being a niche model in VCS design). A lot of VCS have used diffs to implement commits. But... they have also used snapshots from time to (every N commits) in order to make checking out old commits more efficient. Apparently this is how Mercurial works and how either Subversion or CVS implements it. This is based on some article I read yesterday. I could dig it up if this turns out to be wrong.
  - rcxdude 3y ago
    Now that is an implementation detail: all of those tools treat commits as snapshots primarily. Internally they may use diffs in order to compress the data (as does git), but the commits are primarily presented to the user as snapshots, and only secondarily treated as diffs in some circumstances (this flipping is a confusing point, to be fair, and something which git does a lot more of, which I think can add to the confusion. e.g. rebases are really turnings a series of commits into diffs, and then applying those diffs onto a different base commit to create a new string of commits. But the git man page just describes this as 'moving commits'. SVN and CVS just don't support this functionality, and mecurial buries it behind an extension). If you want examples of VCS that treat commits as diffs conceptually, look at darcs and pijul.
avgcorrection 3y ago
> in other words, git makes the most sense if you embrace the inherent leakiness of the abstraction. What about it leaks? I think this term is overrated. https://news.ycombinator.com/item?id=37752291 https://news.ycombinator.com/item?id=37752291 > The problem is that git doesn't really look much like a datastructure at first glance All VCS have a data structure. It's inherent.
- saghm 3y ago
  > All VCS have a data structure. It's inherent. "having a data structure" is very different than "being a unique data structure that you won't encounter anywhere else". I don't think most programmers have implemented their own version control systems, so the idea that needing to learn a new data structure to learn git isn't obvious even if you consider it "inherent"
  - avgcorrection 3y ago
    I was replying to a comment about how the fact that Git has a datastructure (or whatever was meant) is surprising since it's just a command that you call, which is absurd considering what it does (store revision history).

by saghm 3y ago

brabel 3y ago

> arguably the more accurate analogy would be to call them "leaves" I don't think so. Branches are the more accurate analogy because two branches can have many commits on top of each of their common, parent commit - so branches grow as tree branches do, not leaves.

Shish2k 3y ago
> so branches grow as tree branches do, not leaves That’s exactly the mistake though - branches (the implementation detail) don’t grow. Branches - under the hood - are “one pointer to one commit”, and they are always the same size. The suggestion to call the implementation “leaves” is because you get a pointer to one commit at the end of the branch, and you can then follow that branch backwards (via the linked-list of parent-commits) until you reach the trunk. But the “branch” is never actually stored anywhere, it is only implied by its ends.
- brabel 3y ago
  That makes no sense. Different branches always have a common parent commit which is the "branching point". When you update the branch to point to a new commit, your branch is growing apart from the other. The branch analogy makes much more sense.

Izkata 3y ago

I've shown coworkers "git log --graph --oneline --decorate --all -50" many times and always have them start with it (and even use it throughout stepping them through something) to try and show that structure as we go. I think it helps a bit, but their IDEs go to great lengths to keep them out of the command line, so they're never completely sure what happened when it does something odd to their repo.

formerly_proven 3y ago
idk I clicked something and then there was an error so I deleted the project and started over
brabel 3y ago
> but their IDEs go to great lengths to keep them out of the command line Their IDEs can show them the graph you're talking about in a much richer form, lets them navigate through it, check what each commit did, who did it, and even change the graph (as everything in Git is changeable) by removing/rephrasing commits for example. I don't see how using the terminal actually helps anyone understand git, quite the opposite.
- Izkata 3y ago
  From what I've seen, they don't have that functionality. But my favorite is that it has a "sync" button for when a local and remote branch diverge due to a rebase, that doesn't tell you what it's going to do. The one time I saw it in use, it rebased new commits from master onto their branch.
  - brabel 3y ago
    IntelliJ: https://www.jetbrains.com/help/idea/investigate-changes.html https://www.jetbrains.com/help/idea/investigate-changes.html VSCode: https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph https://marketplace.visualstudio.com/items?itemName=mhutchie... or https://github.com/gitkraken/vscode-gitlens#commit-graph- https://github.com/gitkraken/vscode-gitlens#commit-graph- SourceTree: https://confluence.atlassian.com/sourcetreekb/viewing-log-history-of-a-repository-785615840.html https://confluence.atlassian.com/sourcetreekb/viewing-log-hi...

rcxdude 3y ago

> I think the disconnect is that the "first principles" that you can derive from are implementation details; in other words, git makes the most sense if you embrace the inherent leakiness of the abstraction. Of the things mentioned in that comment, only SHA1 is really an implementation detail. The rest, especially how commits and branches relate to each other, is basically the core model of using git. The only thing I'd really adjust in that statement is condensing down the description of trees to "commits are a snapshot of the repository" (as opposed to a diff, which a lot of people seem to think commits are despite it being a niche model in VCS design). (To give an idea, I'd condense SVN's model down to similar terms: commits are a snapshot of the repository given a revision number, and branches are copies of the folder structure, or parts thereof, conventionally under branch/)

avgcorrection 3y ago
> The only thing I'd really adjust in that statement is condensing down the description of trees to "commits are a snapshot of the repository" (as opposed to a diff, which a lot of people seem to think commits are despite it being a niche model in VCS design). A lot of VCS have used diffs to implement commits. But... they have also used snapshots from time to (every N commits) in order to make checking out old commits more efficient. Apparently this is how Mercurial works and how either Subversion or CVS implements it. This is based on some article I read yesterday. I could dig it up if this turns out to be wrong.
- rcxdude 3y ago
  Now that is an implementation detail: all of those tools treat commits as snapshots primarily. Internally they may use diffs in order to compress the data (as does git), but the commits are primarily presented to the user as snapshots, and only secondarily treated as diffs in some circumstances (this flipping is a confusing point, to be fair, and something which git does a lot more of, which I think can add to the confusion. e.g. rebases are really turnings a series of commits into diffs, and then applying those diffs onto a different base commit to create a new string of commits. But the git man page just describes this as 'moving commits'. SVN and CVS just don't support this functionality, and mecurial buries it behind an extension). If you want examples of VCS that treat commits as diffs conceptually, look at darcs and pijul.

avgcorrection 3y ago

> in other words, git makes the most sense if you embrace the inherent leakiness of the abstraction. What about it leaks? I think this term is overrated. https://news.ycombinator.com/item?id=37752291 https://news.ycombinator.com/item?id=37752291 > The problem is that git doesn't really look much like a datastructure at first glance All VCS have a data structure. It's inherent.

saghm 3y ago
> All VCS have a data structure. It's inherent. "having a data structure" is very different than "being a unique data structure that you won't encounter anywhere else". I don't think most programmers have implemented their own version control systems, so the idea that needing to learn a new data structure to learn git isn't obvious even if you consider it "inherent"
- avgcorrection 3y ago
  I was replying to a comment about how the fact that Git has a datastructure (or whatever was meant) is surprising since it's just a command that you call, which is absurd considering what it does (store revision history).