21–30 of 559 posts
Fossil's new(ish) semi-automatic bidirectional interaction with Git mirrors has finally made Mercurial replaceable for me. However, it is hard to ignore that the IT world has mostly decided to settle with whatever is the most commonly used right now, no matter if it is actually the best solution - so at least when it comes to DVCS, the war seems to be over.
- Interoperate with the major player(s), currently Git and in many places unfortunately still Subversion. svn2git probably did more for Git adoption than any other feature or tool, because it allowed a fairly painless transition without losing information.
- Solve at least one big problem with the current contenders. Git made it possible to run VCS without a separate server program and sped up VCS operations massively. Both of those were huge. Looking at the Fossil home page[1] it does have some features I personally have wanted in VCSes, such as integrated "bug tracking, wiki, forum, and technotes," but the devil is very much in the details of how that actually works (How easy is it to write your own custom frontend or add business-critical bug tracking fields, for example?), and it's not like we don't already have good bug trackers, wikis etc.
Just as a tangent, some issues (but not necessarily major or fundamental, depending on who you ask) with Git as it works right now:
- Does not use cryptographically secure hashes, and has no clear migration path to a different hashing mechanism.
- Git Annex is not yet built in.
- The command line is complex, including many niche subcommands and tons of rarely used options.
- The command line is inconsistent, such as `git rm` vs `git branch --delete` vs `git remote remove`.
- It is based on a less than ideal theoretical model of patches[2]. IMO this is the most exciting development in VCSes since Git.
If that never happens, then it's a pretty strong indication that Git is working perfectly fine -- so why worry about whether or not you can replace it?
Earlier quoted context omitted.
SVN also had serious difficulties and performance limitations which git does not. Git is somewhat confusing to use, but not enough so that anyone really cares all that much (besides a few people who really care) and that is not a recipe for easy replacement. There were/are slightly less confusing version control systems (mercurial) but they didn't catch on for whatever reason.
> There were/are slightly less confusing version control systems (mercurial) but they didn't catch on for whatever reason. Also (sorta) darcs, and hopefully pijul. I sincerely hope some patch-based version control can catch on.
The cloud is going to change a lot of stuff, file-system based code might be gone, code-in-database is already halfway here ... opportunity
It is necessary but not sufficient for any new contender to do at least the following to have any chance of taking over: - Interoperate with the major player(s), currently Git and in many places unfortunately still Subversion. svn2git probably did more for Git adoption than any other feature or tool, because it allowed a fairly painless transition without losing information. - Solve at least one big problem with the…
Which is a better choice than Git for most projects, to be honest.
The cloud is going to change a lot of stuff, file-system based code might be gone, code-in-database is already halfway here ... opportunity
I agree with the first half of the statement: we indeed do not have a cloud-first version control system. It could bring some real benefits of tight integration with continuous build and other things considered to be essentials nowadays. I don't see files going anywhere. I would like to listen to examples of "code-in-database is already halfway here", if you happen to have them.
Low-code is very suddenly going to be a big thing in the next couple years and when it happens there are now 750M more "coders" and those types of people are not interested in git pull --rebase --fucked --whatdidido
I am happy to use whatever everyone else starts using, provided it works at least as well. But I also do not have many problems that git won't solve, so I don't feel a burning need to switch. I think git is good enough that source control is no longer a very interesting problem.
It is necessary but not sufficient for any new contender to do at least the following to have any chance of taking over: - Interoperate with the major player(s), currently Git and in many places unfortunately still Subversion. svn2git probably did more for Git adoption than any other feature or tool, because it allowed a fairly painless transition without losing information. - Solve at least one big problem with the…
> unfortunately still Subversion Which is a better choice than Git for most projects, to be honest.