| > The directed acyclic graph is fine. > But that is not really the structure once we start having.... Well, yes, the DAG of commits with trees and blobs attached to them is still the structure of the underlying database, which is what you were originally talking about. But OK, you want to talk about the complexity that arises from git being distributed and having a staging area. That's totally valid, and it's what simplified wrappers like gitless are here to solve. Maybe try those? > Git is a disaster for version control. It excels for one particular use case, and user type. So, because git is excellent at its intended use case, it is a disaster for version control in general? OK... > Part of my work is getting scientists to use version control. Well, maybe your scientists should be using some other version control tool if they are having so much difficulty with git? |
But the standard git interface can not realistically be avoided either. Whether IntelliJ or Atom git plug in, they are all closely modelled on the git commands.
We also have a considerable number of people working on Windows.
The disaster is that because the open source community has entirely embraced git, git is no longer optional. We could try to teach people two tools (pushing git off until later), and it's something we have considered, but that has obvious downsides, too.
It's still something we will investigate, but we are in an extremely resource strapped environment. Time, IT staff, etc...
On a technical note, a single DAG that you append commits to is vastly different from a number of DAGs (technically a directed acyclic forest) that interact in non-trivial ways. So no, the DAG is not the underlying database, it is just a part of it.
Failing to make this distinction is how we end up with millions of tutorials explaining the easy part, and plenty of smart users that still end up with messed up repos.