Allura is an open source implementation of a software forge, a site that manages source code repositories, bug reports, discussions, and more for projects.
Not OP, but personally yes. Every code forge supporting only git just further enforces git’s monopoly on the VCS space. Git isn’t perfect, nor should be treated as perfect.
The above is probably the reason why so many alternative VCS’s have to cludge themselves onto git’s file format despite likely being better served with their own.
Interesting new VCS’s, all supporting their own native format as well for various reasons:
pijul
sapling
jujutsu
Sapling is developed by meta, jujutsu by an engineer at Google. Pijul is not tied to any company and was developed by an academic iirc. If you’re okay with not new:
mercurial
fossil
darcs
VCS’s are still being itterated on and tooling being super git centric hurts that.
It being objectively better then SVN or CVS doesn’t mean that it’s the best we can do. Git has all sorts of non-ideal behaviors that other VCS’s don’t. Pijul’s data structure for instance is inherently different from git and it can’t be retrofitted on top. Making tooling only support git effectively kills off any potential competitors that could be superior to git.
One example is pijul specifically let’s you get away from the idea that moving commits between branches changes their identity, because pijul builds a tree of diffs. If two subtrees of diffs are distinct, they can always be applied without changing identity of those diffs. This means “cherry picking” a commit and then merging a commit doesn’t effectively merge that commit twice resulting in a merge conflict.
The data model there is fundamentally different. That would break how git would work because operations that worked one way before would now no longer work that way. You’d functionally have rewritten and mapped all the old functionality to new functionality with subtle differences, but at that point is it even git? You have a wrapper with similar but subtly different commands and that’s it. It’s like saying “instead of reinventing functionality by building both ext4 and btrfs, why don’t we just improve ext4”?
Not OP, but personally yes. Every code forge supporting only git just further enforces git’s monopoly on the VCS space. Git isn’t perfect, nor should be treated as perfect.
The above is probably the reason why so many alternative VCS’s have to cludge themselves onto git’s file format despite likely being better served with their own.
Interesting new VCS’s, all supporting their own native format as well for various reasons:
Sapling is developed by meta, jujutsu by an engineer at Google. Pijul is not tied to any company and was developed by an academic iirc. If you’re okay with not new:
VCS’s are still being itterated on and tooling being super git centric hurts that.
So what? You speak about git as if it were some half-proprietary solution aimed at maximizing corporate profit. Git isn’t Chrome.
Yes, and because of that fact it has been evolving over the years.
What I see is some resentful people about git - in the same way that happened with SVN and oh well git is objectively better than that.
It being objectively better then SVN or CVS doesn’t mean that it’s the best we can do. Git has all sorts of non-ideal behaviors that other VCS’s don’t. Pijul’s data structure for instance is inherently different from git and it can’t be retrofitted on top. Making tooling only support git effectively kills off any potential competitors that could be superior to git.
One example is pijul specifically let’s you get away from the idea that moving commits between branches changes their identity, because pijul builds a tree of diffs. If two subtrees of diffs are distinct, they can always be applied without changing identity of those diffs. This means “cherry picking” a commit and then merging a commit doesn’t effectively merge that commit twice resulting in a merge conflict.
That’s one example how one VCS can be better.
What if we just upgrade git to have those features instead of reinventing the wheel?
The data model there is fundamentally different. That would break how git would work because operations that worked one way before would now no longer work that way. You’d functionally have rewritten and mapped all the old functionality to new functionality with subtle differences, but at that point is it even git? You have a wrapper with similar but subtly different commands and that’s it. It’s like saying “instead of reinventing functionality by building both ext4 and btrfs, why don’t we just improve ext4”?
The two are practically entirely different.