Been using fossil for several years on my solo projects and loving it. Hoping to see it get wider adoption.
Fossil versus Git
101–110 of 197 posts
Re: Fossil versus Git
#102Wow, small fonts on full screen width. That's why screen readers were invented though.
That's definitely not why. Maybe you mean "reader view"?
Re: Fossil versus Git
#103Earlier quoted context omitted.
Git gets its bias from the Linux kernel development. When you're sharing your source changes with external people, who need to review your code, it just makes sense to present it in a clean, logical progression of changes. To wit, remove unnecessary noise like your development missteps. And it's only in that context that the emphatic call for history rewriting is born. Meaning, you can use all the power of Git to rec…
It feels like overindexing on git as a source of truth for the iterative development process itself is just bikeshedding. Do whatever you want to do locally, then squash your commits into a single unit change. Document that comprehensively in your commit message for that squashed change. If there was some profound learning that feels like it needs rebase history for, just explain it narratively. Perhaps a more conten…
> squash your commits into a single unit change.
Again, Git gets its bias from Linux kernel development. You can not present your entire work as a single unit change to sub-system maintainers for inclusion in the mainline. You can use the power of Git to present it in a digestible way that aids understanding, and allows piecemeal selection of acceptable bits, and rejection of others.
This is clearly not relevant to everyone, but to suggest there is no value at all, is laughable.
Re: Fossil versus Git
#104Stopped 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.…
> And when I do, I can trivially push my repo to GitHub or gitlab or sr.ht or whatever.
And not the wiki, the issues, the releases, the forums, the website, and all that stuff that is probably needed once your project starts to involve a few people.
Re: Fossil versus Git
#105Lots of people are saying that having large files in a repo is wrong, bad, bad design, incorrect usage. Forget that you know git, github, git-lfs, even software engineering for a moment. All you know is that you're developing a general project on a computer, you are using files, and you want version history on everything. What's wrong with that? The major issue with big files is resources: storage, and network bandwi…
Git is designed with a strong emphasis on text source and patches. It simply isn't designed for projects with large assets like 3D animation, game dev, etc. Having said that, solutions like LFS, Annex and DVC (not git-specific) work really well (IMO). If you don't like that, there are solutions like Restic that can version large files reasonably well (though it's a backup program).
Re: Fossil versus Git
#106I 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.
Then don't use those features. Do you know how many commands Git has specifically for formatting/sending/applying patches via email?
Re: Fossil versus Git
#107Stopped 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.…
> my car won’t start because I’m out of coffee grounds
I'd call this a straw man but it's way past that...
Re: Fossil versus Git
#108Didn't know about fossil. It's unfortunate many people are saying they stopped reading at the "fossil is everything into one" part because It still looks an interesting way of doing vcs. > 95% of the code in SQLite comes from just four programmers, and 64% of it is from the lead developer alone. The SQLite developers know each other well and interact daily. Fossil was designed for this development model. They propose…
I haven’t used Fossil but I have used gittrac, cvstrac in git mode. Cvstrac was what SQLite used before fossil, basically wiki and issue tracker built on top of SQLite, just add CVS, SVN or Git. A very small system compared to Gitea or other forges, but incredibly powerful thanks to SQL and very productive. Fossil is just the logical continuation and shares the same clarity of design and elegant implementation of SQLite.
Re: Fossil versus Git
#109I 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…
It is extremely rare that I have a file over 100MB. I also think it’s one of those situations where if I have a giant binary file in source control “I’m doing it wrong” so git helps me design better. It’s like in the olden days when you couldn’t put blobs directly in a row so databases made you do your file management yourself instead of just plopping in files. I like git. I don’t like giant binary files in my commit…
In the age of Large Language Models, large blobs will become the rule, not the exception. You’re not going to retrain models costing $100M to build from scratch because of the limitations of your SCM.
Re: Fossil versus Git
#110Earlier quoted context omitted.
It feels like overindexing on git as a source of truth for the iterative development process itself is just bikeshedding. Do whatever you want to do locally, then squash your commits into a single unit change. Document that comprehensively in your commit message for that squashed change. If there was some profound learning that feels like it needs rebase history for, just explain it narratively. Perhaps a more conten…
> squash your commits into a single unit change. Again, Git gets its bias from Linux kernel development. You can not present your entire work as a single unit change to sub-system maintainers for inclusion in the mainline. You can use the power of Git to present it in a digestible way that aids understanding, and allows piecemeal selection of acceptable bits, and rejection of others. This is clearly not relevant to e…
> You can not present your entire work as a single unit change to sub-system maintainers for inclusion in the mainline.
If we take away “this is how it’s historically done” or “because I know how these maintainers act and they would not accept it” - why not? From what principles is the Linux kernel special that standalone incremental units of change are inappropriate or undesirable?
> allows piecemeal selection of acceptable bits, and rejection of others
Sure, is a good thing, but doesn’t have much to do with git and can be done without rebasing.