What's stopping us from just using those words to describe operations with Git?
I mean, what Git is, is a data structure with a set of operations on it, and the design of that is pretty fundamental at this point. We'd need to see something more novel[1].
(Sidenote: Git almost seemed an obvious trajectory for version control given how problematic file-based approaches have been. I've used far too many version control systems, including "ancient" awful ones like Harvest[2], and it just felt inevitable that we'd one day rely on an "always-branching" model.)
[1]: I did think of something more novel: semantic version control (https://news.ycombinator.com/item?id=25537455)
[2]: https://en.wikipedia.org/wiki/CA_Harvest_Software_Change_Man...
(Unless I guess we're talking forks of MySQL.)
I don't know if maybe you have a good example...?
The protocol has become a bit smarter, by allowing there to be additional options passed for different communications options, and there is a slow but steady progress of moving from sha1 to sha256 for the hash function, but that isn’t rolled out yet completely.
Different tools have been added over time but the internals are pretty much the same as they’ve always been.
Of that was the case then how come Git reigns supreme in spite of the lack of a polished UI/UX?
The huge existing body of documentation, tutorials, StackOverflow questions, etc. that use the confusing standard Git terminology.
I feel like making collaboration less painful has been the greatest innovation driver in the last few decades, and has paid off absolutely enormously. Imagine where a git/Github for other disciplines could take us. Given software developers build such tools, and given software developers overwhelmingly know how neat git really is, it's actually kinda strange that there's still such a dearth of good solutions in this space.
I would love to collaborate but when I start looking into git the amount of stuff I don't fully understand keeps growing. I should want something in my work flow that I don't understand? If it stops working just like that, the way everything seems to, I'm suppose to fix something that I don't understand?
When trying to figure out how it worked I read discussions from truly experienced users who decades into the process apparently still had to learn now to unstuck themselves.
I'm not saying its bad at what it does. Its much worse, I have no idea what the point is. It seems tailored to manage top of the developer pyramid issues that I imagine to be hard enough to justify its existence.
In applications I've seen copies of data get modified in different places then merged back together again. Its a horror movie!
As a lone developer, it lets you easily snapshot the state of your code at appropriate points and then compare those to the current state to find out what you broke. Of course, you can also do this by making copies manually, but that gets complicated if the program consists of more than file.
The real benefit is when you have more than one developer working on the program. If you make some changes on your machine, and I make some changes on my machine, and when we're done we want a single unified version of the program (with both your changes and mine) in order to deploy it, what should that look like? If all we can see is that line 123 in some file is different in your version and my version, how do we know which version of that line we want?
Git keeps track of (in the form of a graph structure) the fact than your version 1 is a descendant of our original version, your version 2 descends from your version 1, my version 1 descends from the original version, and so on ... and when we merge our versions, we get a final version that descends both from your latest version and mine.
You could do all this bookkeeping manually and figure out what to diff against what, but git gives you tools to work with.
...and manual copies don't offer you the great automations that git provides you for free, like being able to tell when exactly each line has been changed last time (so you can check the whole context of how and why that change was made) or perform a binary search of a revision that introduced a bug. Even when working alone, these tools are invaluable.
We don't expect the average person to understand the tools and workflow of a mechanical engineer working with SolidWorks PDM - we shouldn't expect the average person to understand git (which is basically the software equivalent). I've never disagreed with the arguments that git is confusing or difficult to learn for non-software-developets, but I've never really understood why that's a problem.
Everyday folks aren't expected to know how their car works, much less tinker with it. Not the enthusiasts, who will find a way to grok the full specs of cars and tinker even if you tell them not to.
Normal everyday folks should be content leaving the gory details to their mechanics. I'd wager it to be the same with Git, as an everyday tool of software engineers, rather than that of layperson. This is not gatekeeping; it's a fact that Git is not your usual point-and-click stuff and UIs that attempt to do so can only simplify it so much. Real enthusiasts can always learn how to use Git if they want to, there's no need to make it simpler or easier for the 'casuals'.
The fact that people even have trouble with self-descriptive software like Microsoft Word - which is probably, in terms of UI, one of the easiest, most accessible UIs ever with years of research and iteration - speaks to the fact that not everyone will 'get' Git, nor sho uld there be a need to please or try to reach to everyone with a software that has as many complicated features as it does for the multitude of engineering problems it tries to solve.
If that were actually the case, then the dominant programming language today would be COBOL, rather than anything we have now.
The difference between my example vs. what you defined, is that hype and/or popularity determine what people use for _new_ projects. But that doesn't really assess how dominant a language has been in the past (or even in production currently).
Java is another dominant language that you might not use for a new project. Same with C.
That definition biases towards verbose languages with lots of headers and boilerplate code (e.g. C++, Java)
I would very much consider using Java for a new project, same with C(1) if the project is in "real time" (I think that C++ hides too much things under the rug which can create latency issue).
1: Zig isn't ready yet to be a replacement
Those are the usecases that Git already handles. Each and every single one of them. Somehow you conspicuously left branching out of it, which is the main value added by any version control system along with merging. Thus I really don't see the point of arguing that Git will be replaced by a tool that does exactly what Git has been doing by design since it was released.
You really want to record, mapped X to Y. Not 500 files changed in 4218 places.