For developers new to Git, I like to tell them that Git is not a version control system at all.
It's a set of tools with which one can build a number of different, and largely interoperable, version control systems.
Github, for example, is one such, as is Gitlab. The way I work with Git locally doesn't really match Github or Gitlab, but this doesn't matter much because I can export data between them easily enough. There really is no wrong way to use Git. Well, not true - you can shoot yourself in the foot with Git if you so desire - but any workflow you like is just fine. It does not impose any particular workflow on the developer.
It's easy to forget that Git was designed exactly like this, as a set of low-level primitives that people would glue together any old how. There was a strict division between "plumbing" and "porcelain" that probably only exists now in the minds of the Git developers themselves.
The other way that Git broke the mould was that it was built to be a mutable history. That in itself ran against everything that a version control system should be, many thought - and the rebase/squash/split workflow is certainly that hardest to get to grips with. But this opens up vast possibilities for workflows that nobody could have considered before.
Because of these two factors, I don't see Git being supplanted - it's simply built in such a way that it can incorporate many new ideas without drastic rearchitecting.
But it is always a good idea to look at other systems to harvest other good ideas. Git is flexible enough, after all, to integrate some pretty funky workflows.
As a first step, you should go look at Monotone. Monotone is Git's spiritual father - it's driven by a classical database (sqlite, as I recall), but is otherwise fairly similar to a typical version control system build with git. It has branches, SHA hashing, no version numbering, etc. It goes a little further in terms of security (though Git has caught up), but crucially, these are the guys that invented many of the concepts, like a Directed Acyclic Graph for versions, that Linus then used much more efficiently in Git.
The Monotone project came up with some wonderfully byzantine ideas. For example, to fix a bug, you identify when the bug was introduced, and branch there. You then fix the bug in this new branch, and then merge the result to any downstream branches of the commit the bug was introduced in. Now, you can identify the revisions in which the bug is present by where the bug-fix branch is not yet merged. The basic idea of using branches very fluidly is certainly prominent in most Git workflows, but the notion of using them directly as bug tracking is definitely a new concept.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For developers new to Git, I like to tell them that Git is not a version control system at all.
It's a set of tools with which one can build a number of different, and largely interoperable, version control systems.
Github, for example, is one such, as is Gitlab. The way I work with Git locally doesn't really match Github or Gitlab, but this doesn't matter much because I can export data between them easily enough. There really is no wrong way to use Git. Well, not true - you can shoot yourself in the foot with Git if you so desire - but any workflow you like is just fine. It does not impose any particular workflow on the developer.
It's easy to forget that Git was designed exactly like this, as a set of low-level primitives that people would glue together any old how. There was a strict division between "plumbing" and "porcelain" that probably only exists now in the minds of the Git developers themselves.
The other way that Git broke the mould was that it was built to be a mutable history. That in itself ran against everything that a version control system should be, many thought - and the rebase/squash/split workflow is certainly that hardest to get to grips with. But this opens up vast possibilities for workflows that nobody could have considered before.
Because of these two factors, I don't see Git being supplanted - it's simply built in such a way that it can incorporate many new ideas without drastic rearchitecting.
But it is always a good idea to look at other systems to harvest other good ideas. Git is flexible enough, after all, to integrate some pretty funky workflows.
As a first step, you should go look at Monotone. Monotone is Git's spiritual father - it's driven by a classical database (sqlite, as I recall), but is otherwise fairly similar to a typical version control system build with git. It has branches, SHA hashing, no version numbering, etc. It goes a little further in terms of security (though Git has caught up), but crucially, these are the guys that invented many of the concepts, like a Directed Acyclic Graph for versions, that Linus then used much more efficiently in Git.
The Monotone project came up with some wonderfully byzantine ideas. For example, to fix a bug, you identify when the bug was introduced, and branch there. You then fix the bug in this new branch, and then merge the result to any downstream branches of the commit the bug was introduced in. Now, you can identify the revisions in which the bug is present by where the bug-fix branch is not yet merged. The basic idea of using branches very fluidly is certainly prominent in most Git workflows, but the notion of using them directly as bug tracking is definitely a new concept.