> Or is it a solved problem and Git is the endgame of VCS
I've read so many comments to the effect that "X is a solved problem" when it clearly wasn't that I've come to conclude that the phrase means the opposite of its surface value...
I'm pretty sure that Git is not the end-of-line as far as VCSs go. Whether I will ever change my VCS, again, ever, that is an entirely different question. I've been through so many of them (RCS; a bit of CVS; a bit of Subversion which promised to be CVS-without-the-flaws, which it was not; Mercurial, because hey it was written in Python, so must be good, right? right?; finally Git; and of course the usual `report-v4-revision-good-one.doc` renaming game; plus a plethora of backup solutions, some really bad ones among them)—so many of them I'd be loathe to switch to yet another one, except maybe Fossil, which I almost did.
So yeah, I had totally forgotten about https://fossil-scm.org ; the reason it didn't become my go-to solution is probably mainly the fault of github.com, which I find too good to be ignored, and I don't want an 'impedance mismatch' between my system and their system. But maybe it would be doable and maybe Fossil is good enough to be worth it; at any rate, go read their docs, especially where they compare themselves directly to Git and give lots of good reasons for their way of doing things. This is the same people who are doing SQLite, so I'd say a trustworthy source of reliably top quality software.
Other than that, my personal way of dealing with the complexities of Git is to avoid using parts that I don't need or don't know about well enough (i.e. almost all of it). I use it to check in changes, give one line of comment, and upload to github.com; then of course cloning and updating existing repos as well as setting up a new ones is within my skill set. Branching and merging not so much. So it's like `git` plus `clone`, `add`, `commit`, `push`, that's all; also, I use Sublime Merge for part of these (reviewing changes, adding related changed chunks, commit) which I must recommend for the piece of fine software that it is.
I also at some point toyed with gitless (I think it was called) which promised to be Git, but simpler for the simple things and you can always fall back to Git proper where called for; this I find a good proposition that I like (Markdown: fall back to HTML; CoffeeScript: fall back to JavaScript) but somehow gitless didn't stick with me; I guess that's b/c I've already tempered down my usage of Git to a point near absolute zero, and command line history + Sublime Merge does the rest.
> github.com…I don't want an 'impedance mismatch' between my system and their system
So give your contributors developer accounts on your Fossil instance, which is super-cheap to set up, being a single binary with nearly zero external dependencies. (Those being OpenSSL and zlib, which are table stakes these days.) My containerized build is a single static binary that compresses to ~3.5 MB, total, all-in.
If you're concerned over the lost promise of easy PRs from randos on the Internet, I question your premise. My experience is that below a certain project popularity level, there is less than one total full-time developer on the project, even counting all possible external committers. Below this threshold, why optimize for external contributors? If someone has a sufficiently valuable patch, they can deal with getting a Fossil repo login or sending a patch.
I've been the maintainer of a piece of software for coming on two decades that's in all popular package repos and have _never_ gotten a worthwhile PR for it via GitHub. I spend more time using their code commenting features explaining why this, this, and this make the change unacceptable, after which the PR submitter goes away rather than fix their patch. It's a total waste of time.
I did once upon a time get high-quality external contributions, but that was back when the project was hosted by Subversion, and it didn't matter that posting patches required more work than firing off a GH PR. People who have sufficient value to commit to a project will put up with a certain level of ceremony to get their code into the upstream project.
(To be fair, I expect the reason for the lack of quality external contributions is that the project is in some sense "done" now, needing only the occasional fix to track platform changes.)
If you are lucky enough to have an audience of outsiders who will provide quality contributions, Fossil does have a superior option for patches than unified diffs. See its "patch" and "bundle" commands. This lets your outsiders send a full branch of commits with comments, file renames/deletions, etc.
…kind of like a PR. :)
If you absolutely require integration with Git-based tooling, Fossil makes it easy to mirror your repo to GitHub, which you can treat as read-only.
I've read so many comments to the effect that "X is a solved problem" when it clearly wasn't that I've come to conclude that the phrase means the opposite of its surface value...
I'm pretty sure that Git is not the end-of-line as far as VCSs go. Whether I will ever change my VCS, again, ever, that is an entirely different question. I've been through so many of them (RCS; a bit of CVS; a bit of Subversion which promised to be CVS-without-the-flaws, which it was not; Mercurial, because hey it was written in Python, so must be good, right? right?; finally Git; and of course the usual `report-v4-revision-good-one.doc` renaming game; plus a plethora of backup solutions, some really bad ones among them)—so many of them I'd be loathe to switch to yet another one, except maybe Fossil, which I almost did.
So yeah, I had totally forgotten about https://fossil-scm.org ; the reason it didn't become my go-to solution is probably mainly the fault of github.com, which I find too good to be ignored, and I don't want an 'impedance mismatch' between my system and their system. But maybe it would be doable and maybe Fossil is good enough to be worth it; at any rate, go read their docs, especially where they compare themselves directly to Git and give lots of good reasons for their way of doing things. This is the same people who are doing SQLite, so I'd say a trustworthy source of reliably top quality software.
Other than that, my personal way of dealing with the complexities of Git is to avoid using parts that I don't need or don't know about well enough (i.e. almost all of it). I use it to check in changes, give one line of comment, and upload to github.com; then of course cloning and updating existing repos as well as setting up a new ones is within my skill set. Branching and merging not so much. So it's like `git` plus `clone`, `add`, `commit`, `push`, that's all; also, I use Sublime Merge for part of these (reviewing changes, adding related changed chunks, commit) which I must recommend for the piece of fine software that it is.
I also at some point toyed with gitless (I think it was called) which promised to be Git, but simpler for the simple things and you can always fall back to Git proper where called for; this I find a good proposition that I like (Markdown: fall back to HTML; CoffeeScript: fall back to JavaScript) but somehow gitless didn't stick with me; I guess that's b/c I've already tempered down my usage of Git to a point near absolute zero, and command line history + Sublime Merge does the rest.