Live data from Hacker News

Fossil versus Git

fossil-scm.org

181–190 of 197 posts

Re: Fossil versus Git

#181
post #153

Earlier quoted context omitted.

Then use a binary repository like Artifactory which has LFS support. You can still version them in git- just don’t store them in there

> Then use a binary repository [...] You can still version them in git- just don’t store them in there So git works, as long as you include things that aren't git to handle what it can't. Stockholm syndrome really blinds people

Not sure if you were agreeing with me or not BUT I run into this often where people do not use the right tools and try to make one tool fit every CM scenario. SharePoint sucks but it has its place. Along with Artifactory/Nexus

Re: Fossil versus Git

#182

Lacks (2020) in title. This article is written in Feb. 2020.

The document first appeared 2010-11-11. The latest change was on 2023-05-10. See https://www.fossil-scm.org/home/finfo/www/fossil-v-git.wiki for a complete change history for the document - including changes on branches.

Aside: How would you get this information (the complete change history in a single file of a larger project) if the repository was on GitHub?

Helpful hint: Click two nodes on the graph to see a diff between the two selected versions.

Re: Fossil versus Git

#183

A large number of Fossil positives are related to not having rebase. It feels like this is a huge concern for functionality that many people, do not use that often. The last time I used rebase at a job was maybe 5 years ago? Other than that my bigger gripe is when I read something like this: > Git strives to record what the development of a project should have looked like had there been no mistakes Git does not striv…

Forgive my dumb question, how do you avoid rebase (ex: when making PR)?

Re: Fossil versus Git

#184
post #150

Git is an absolutely abysmal industry standard and as far as I'm concerned is further proof of my theory that tech is lacking (and actively discourages) much-needed creatives from the field. With them having more representation we would have replaced it years ago.

In what way is git evidence of a lack of creatives? I don’t see the connection.

Re: Fossil versus Git

#185
post #19
post #18

I once tried it and ended up losing the history for some weird reason. Maybe its a fixed bug by now, but if I don't want to use git, I will use mercurial.

It's also hard to go through the trouble of onboarding onto a VCS other than Git given a) how ubiquitous it is even and specially in free hosting services, b) Git alternatives don't offer any compelling feature other than contrarian bragging rights for not using Git.

> b) Git alternatives don't offer any compelling feature other than contrarian bragging rights for not using Git.

oh boy

Re: Fossil versus Git

#186
post #108

Earlier quoted context omitted.

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 SQL…

Can fossil be better than git for a solo personal project or does it add too much stuff on top that's useful once you have a few people working together and it's much simpler to just git commit?

I suspect it will work better, but you have to convince all the other collaborators to also switch, as well as lose tooling in say, Xcode.

Re: Fossil versus Git

#187
post #52

Earlier quoted context omitted.

"One thing" depends on how you squint, though. If you view "version and track text information" then it makes sense to store tickets, wiki, code, yadda under the same tool.

I'm primarily a command line user, I don't use explorer to view, rename, move, copy files etc. Like I said, unix-y. If you think "manage computer stuffs" the OS should bundle all tools anybody could ever want.

And yet you don't use different file systems for small files vs large files, for text vs movies. One assumes that a filesystem can handle all of that kind of data. But one layer above we don't want all those under a unified interface.

Re: Fossil versus Git

#188

A large number of Fossil positives are related to not having rebase. It feels like this is a huge concern for functionality that many people, do not use that often. The last time I used rebase at a job was maybe 5 years ago? Other than that my bigger gripe is when I read something like this: > Git strives to record what the development of a project should have looked like had there been no mistakes Git does not striv…

Forgive my dumb question, how do you avoid rebase (ex: when making PR)?

Generally you merge main into your branch to resolve the conflicts there, then push to make the PR. Sometimes it's easier to rebase, sometimes easier to merge your main. The frequency of one or the other being more useful/easier often influences the accepted workflow.

Re: Fossil versus Git

#189
post #52

Earlier quoted context omitted.

I'm primarily a command line user, I don't use explorer to view, rename, move, copy files etc. Like I said, unix-y. If you think "manage computer stuffs" the OS should bundle all tools anybody could ever want.

And yet you don't use different file systems for small files vs large files, for text vs movies. One assumes that a filesystem can handle all of that kind of data. But one layer above we don't want all those under a unified interface.

> And yet you don't use different file systems for small files vs large files, for text vs movies.

Um, yes, I do. Not that it matters anyway, filesystems are not optimized to handle source code to begin with, they deal well with sectors/blocks and do that well.

Re: Fossil versus Git

#190
post #141

Earlier quoted context omitted.

First, those are bolt-ons and I don’t actually want them tied to the source code management system. Second, for my repos, I use markdown directly in the repo instead of a wiki. This works better for me because the version history is in the repo and for wikis the author is important context for the value of the information. Third, I build my website using an ssg that builds off my repo. Typically this is Jekyll script…

The mistake is assuming that fossil is simply a source code management system, it is not. Fossil is closer to a collaboration system around source code. If you can live your life without it, good. But if I want to use a GUI with links instead of markdown files in a repo from which I can't click to go to the next article, an ssg and a dependency on Github/Gitlab/whatever host I store my code in, and other tools, then…

The article title is git vs fossil. So it’s not just my mistake.

Based on the popularity of the projects, it seems the mistake of the fossil team is that they think they are competing with git.

I look forward to fossil supporting git and then I might consider using it.

Post reply on HN