Stopped reading at first point; why would I want my versioning system coupled to a bunch of random services?
Doing one thing and one thing only is a feature, not a bug.
Fossil versus Git
21–30 of 197 posts
Re: Fossil versus Git
#22Earlier quoted context omitted.
Well, do you use GitHub or an equivalent? The point of this, as the article states: > These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design, to the point that it approximates "GitHub-in-a-box. I’ve not used fossil, but I appreciate this idea. Sure, it’s not unixy, but maybe a VCS reasonably demands such features, and today, it’s not as though the…
To clarify the actual benefit: this means that tickets, etc. are also distributed, i.e. available and backed up locally with every contributor, and not dependent on lock-in to a single vendor like GitHub. Edit: and yes, of course there are downsides as well. It's up to you to weigh them against each other.
I understand, I don’t care about that.
Re: Fossil versus Git
#23I keep coming back to fossil again and again, despite git having a huge pull because of the easy publishing and collab on github/gitlab. Just the other day I was starting an exploratory project, and thought: I'll just use git so I can throw this on github later. Well, silly me, it happened to contain some large binary files, and github rejected it, wanting me to use git-lfs for the big files. After half an hour of no…
if you have large files in your repository, you have a design problem.
Re: Fossil versus Git
#24Earlier quoted context omitted.
Well, do you use GitHub or an equivalent? The point of this, as the article states: > These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design, to the point that it approximates "GitHub-in-a-box. I’ve not used fossil, but I appreciate this idea. Sure, it’s not unixy, but maybe a VCS reasonably demands such features, and today, it’s not as though the…
To me it feels like, rare and smart ones, trying to penetrate giant markets with all in one solutions. I'm not even mad. But find it hard to comprehend who would make such change. Probably they want to test their patience and expect considerable userbase in 30 years, finally monetize it.
Or they just made a tool that solves a problem for them.
This whole article is pretty much why fossil was made.
Re: Fossil versus Git
#25The whole point that git rejects large blobs is primarily because they don't belong in VCS. But for those who need large blobs there is git-lfs as the author mentioned. I don't see a problem with that approach because I personally don't like my git repos growing large after just a few commits which then takes up time for huge clones by other devs. This is the whole principle behind monorepos. If going the monorepo route it's in a teams or projects best interest by keeping the repo size small so new clone by newly onboarded devs or during a CI pipeline don't take forever.
Fossil is an all in one VCS with wiki, issues etc which I don't appreciate because for one it's not feature rich and for another it bloats the backups and restores. So I prefer gits Unix philosophy of doing one thing but doing it really well.
There are some philosophical amd usability differences between fossil and git too but in the grand scheme of things it doesn't matter when one has been using git for a long time. Fossil doesn't have an ecosystem either and making it work with CI CD is a pain because CD tools like agrocd or flux or CI tools like gitlab/gitbub/circle/travis CI systems don't work with fossil out of the box.
Re: Fossil versus Git
#26I love git and I find no reason to look for anything else. Most of the complains I hear from git is from people that could not learn its logic. I think a lot of things could be built on top of git.
Agreed. Over 10 years of development using Git and I perhaps ran into an issue like 10 times, which is once a year on average.
I can't think of any other tool that hasn't given me headaches at least once a day.
Git is actually remarkable tech and its unfortunate that the prevailing hivemind opinion is that its bad.
Re: Fossil versus Git
#27I don't know Fossil. However, the first entry in the comparison table puts me off. "VCS, tickets, wiki, docs, notes, forum, chat, UI, RBAC" I don't want my version control system to be a wiki. Or a chat app, or any of that.
I agree. But tickets... maybe. Issues feel integral to a project. -- it's weird they depend on what server you put stuff on.
Re: Fossil versus Git
#28Earlier quoted context omitted.
Well, do you use GitHub or an equivalent? The point of this, as the article states: > These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design, to the point that it approximates "GitHub-in-a-box. I’ve not used fossil, but I appreciate this idea. Sure, it’s not unixy, but maybe a VCS reasonably demands such features, and today, it’s not as though the…
To clarify the actual benefit: this means that tickets, etc. are also distributed, i.e. available and backed up locally with every contributor, and not dependent on lock-in to a single vendor like GitHub. Edit: and yes, of course there are downsides as well. It's up to you to weigh them against each other.
Yeah, I really want to solve merge conflicts on tickets.
Re: Fossil versus Git
#29Earlier quoted context omitted.
Well, do you use GitHub or an equivalent? The point of this, as the article states: > These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design, to the point that it approximates "GitHub-in-a-box. I’ve not used fossil, but I appreciate this idea. Sure, it’s not unixy, but maybe a VCS reasonably demands such features, and today, it’s not as though the…
Gitea is already "GitHub in a box". Also, GitHub is not something to emulate, it is the lowest common denominator of repo hosting.
> Also, GitHub is not something to emulate, it is the lowest common denominator of repo hosting.
What do you mean by this? Having mostly used git and github, I don't really know what I'm missing.
Re: Fossil versus Git
#30Stopped reading at first point; why would I want my versioning system coupled to a bunch of random services? Doing one thing and one thing only is a feature, not a bug.
Wouldn’t it be great if my car also brewed coffee?
I drink coffee every day on the way to work.
I’m always in a hurry. It would be convenient to just build that in.
I always drink coffee while driving, I may as well just build it in.
Cut to a month later because my car won’t start because I’m out of coffee grounds.
This is how fossil seems to me.
I probably have hundreds of repos with just versioned files. That’s it. I don’t want an issue tracker and chat and everything else in my git.
And when I do, I can trivially push my repo to GitHub or gitlab or sr.ht or whatever.
Comically, I’d probably use the fossil service if it supported git.
Anyone else remember when Google Code only supported mercurial? And they talked about how much better mercurial was than git. And they were right. And no one cared.
I hope fossil sticks around because I like more services.
But if I was interviewing for a company and they said that I must use fossil, I probably wouldn’t work there. (This is similar to if they said you must use TFS or something else weird)
I’ve used so many version controls over the years (vss, cvs, subversion, clearcase, perforce, bitkeeper, tfs, mercurial, manual file system hacks) and I need a really good reason to use something other than git. Making it more complex is not a reason I accept.