3 ms·

The model's basically a directed acyclic graph (not a tree), with each edge being the diff between the two nodes it connects. I think the UX could be improved i

• avar 4y ago
  It stores a full copy of every node, not the diff. The diff is just something that's rendered on-demand, and "gc"/"repack" compaction and it being content-addressable makes sure that the storage space doesn't balloon as a result of everything being a full snapshot. This distinction makes a difference in some cases, there are other VCSs that store diffs as a fundamental property. About your naming suggestion: I'm not saying you're wrong, but consider that git is used by a very wide audience, and even a lot of the programmer crowd isn't familiar with the graph theory terms you're using. So "branch", "tip" etc. is by no means perfect, but I think it's probably better.
  • flir 4y ago
    There are a lot of people, even in this comment section, whose internal model of git is "it's a tree". Langauge like "branch" reinforces that model, and I don't think it does beginners any favours in the long run. Something something leaky abstractions maybe? (Maybe you're right and I'm being a bit ivory tower here).
    • avar 4y ago
      Even if you suppose that Git had some extreme UX overhaul to the point of renaming builtins like "branch", the existing names would still survive in the popular zeitgeist, as they predated Git. So, I think it's an interesting thought experiment, but practically speaking a non-starter. You'd never be able to fully migrate over, instead it would be another case of that xkcd about N standards.