Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fossil versus Git

fossil-scm.org

Post reply on HN
Print view View original

171–180 of 197 posts

Re: Fossil versus Git

#171

Post by remram »

prepend wrote: post #159
remram wrote: post #133

Earlier quoted context omitted.

Fossil's source control doesn't break if the issue tracker or wiki is misconfigured or disabled. Just like your imaginary car-with-a-coffee-machine would not fail to drive if it were out of coffee grounds. Saying "I don't want my version control to break because of misconfigured wiki" would have already been a straw man, adding this BS about cars making coffee just makes it more insane of an argument.

I disagree. Im sure fossil designers don’t want the whole thing to break if the wiki breaks, but have you tested it? I don’t know what dependencies it has or how well it’s designed. Im not worried about it being turned off. I’m worried about a bug in the wiki portion killing the “important” version. But my argument is that I don’t want my important thing I care about doing unimportant things I don’t care about. I lov…

Do you use all of Git's features? Bundles, emailing, git-daemon? Submodules?

I wonder if you were aware that git contains an IMAP client.

Re: Fossil versus Git

#172

Post by polotics »

prepend wrote: post #159
remram wrote: post #133

Earlier quoted context omitted.

Fossil's source control doesn't break if the issue tracker or wiki is misconfigured or disabled. Just like your imaginary car-with-a-coffee-machine would not fail to drive if it were out of coffee grounds. Saying "I don't want my version control to break because of misconfigured wiki" would have already been a straw man, adding this BS about cars making coffee just makes it more insane of an argument.

I disagree. Im sure fossil designers don’t want the whole thing to break if the wiki breaks, but have you tested it? I don’t know what dependencies it has or how well it’s designed. Im not worried about it being turned off. I’m worried about a bug in the wiki portion killing the “important” version. But my argument is that I don’t want my important thing I care about doing unimportant things I don’t care about. I lov…

This is mistaking the teams that design cars and most software, for the team that designs SQLite and Fossil.

Most software development shops are low quality dysfunctional politics-ridden heavily coupled messes using tools designed for a use-case that is only vaguely similar to the tasks at hand. For example: git, Jira, Confluence, GitHub... In such an environment having one tool that does everything is a recipe for disaster: everyone knows all tools are shoddy and/or misapplied, and can only barely do their own job, they should not touch any other task. SQLite and Fossil are in a completely different world of hard-core quality focus...

Re: Fossil versus Git

#173

Post by sausagefeet »

nightfader wrote: post #49
sausagefeet wrote: post #41

Earlier quoted context omitted.

Why use git at all then? Just use an object store with versioning turned on.

Because git excels in relatively small size text files and patching and difficult. You can't binary blobs like jpegs, audio, video easily.

But that's my point: why can't a version control system be good for this as well? It's the same thing underneath. Why do we have to split these different use cases across different tools and hope a foreign key constraint holds?

Re: Fossil versus Git

#174

Post by sgbeal »

mkl wrote: post #99
maccard wrote: post #76

Earlier quoted context omitted.

I'm not a fossil user but https://fossil-scm.org/home/help/purge

And yet: > FURTHER WARNING: This command is a work-in-progress and may yet contain bugs.

> FURTHER WARNING: This command is a work-in-progress and may yet contain bugs.

Purging and shunning are two entirely different things in fossil. Shunning is for removing "bad" content and purging is very specifically for use with the "bundle" command (a rarely-used option for submitting "drive-by patches" initially conceived as fossil's counterpart to pull-requests).

Re: Fossil versus Git

#175

Post by [deleted] »

rewmie wrote: post #149
appplication wrote: post #97

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

> Perhaps a more contentious take: rebasing doesn’t bring any real value. I strongly disagree. I rebase feature branches on a daily basis and it's a must-have feature for anyone who works on feature branches that you want to keep updated and mergeable as fast-forward merges and ideally peel off small commits in separate pull requests. Here's a small example of a very mundane workflow. I was assigned an issue where I…

[deleted]

Re: Fossil versus Git

#176

Post by sgbeal »

prepend wrote: post #129
Skinney wrote: post #114

Earlier quoted context omitted.

If your car followed the unix philosophy you’d have to bring your own radio and AC.

Right. It’s a careful balance of what to include and what not to include. I don’t know the exact dividing line for “do one thing” but I think that modularity and composability is important. I like having an AC in my car. But I don’t want AC to be a dependency for my car. I like chaining tools together, but work to minimize the required dependency among tools. I think in principle, it’s good if you can install compone…

> Right. It’s a careful balance of what to include and what not to include.

(A long-time fossil dev here...)

The single most important criteria for new features in fossil is, quite simply, "is it useful to fossil's own developers?" Countless times, Richard (the project lead) has found a personal SCM itch in the sqlite project and, a few hours later, committed a feature to fossil to handle that.

Fossil is, and always has been, first and foremost, a tool to manage the sqlite project's source code, and sqlite's development is still a primary driver for new features in fossil. None of the features are sqlite-project-specific, but many of the derive from the needs of that project.

Re: Fossil versus Git

#177

Post by sgbeal »

prepend wrote: post #162
Skinney wrote: post #140

Earlier quoted context omitted.

Fossil doesn’t have a dependency on chat, forum, wiki or issues. They’re included, part of the same product. But if you don’t want it, then you don’t have to use it. Just like you don’t have to turn on the radio or AC in your car. Just like all the email related stuff in Git. And, just because they’re included doesn’t mean they detract the value of the other stuff that is there. A car without an AC isn’t better to dr…

> And, just because they’re included doesn’t mean they detract the value of the other stuff that is there. I think this is a philosophical preference. I think they do detract because they make the system more complex. And fossil developers work on that instead of the think I want. So there’s a cost there. Having an AC and radio in a car increases its price. Not by much but by something. If designers didn’t work in th…

> And fossil developers work on that instead of the think I want.

While also inviting you to join the development team and scratch your own personal itches.

The overwhelming majority of fossil features were implemented by someone scratching a personal itch, not someone scratching random internet-goers' itches.

Re: Fossil versus Git

#178

Post by afiori »

maccard wrote: post #82
afiori wrote: post #67

Earlier quoted context omitted.

I am not saying that it is a better UX, but hashed/versioned blobs on S3 would mostly work depending on tooling integration.

That's building a custom version control on top of the version control you're already using.

not really, it is like building a custom storage layer for your VCS.

you are still relying only on git as a source of truth for which artefacts belong to which version.

Re: Fossil versus Git

#179

Post by afiori »

msk-lywenn wrote: post #70
afiori wrote: post #67

Earlier quoted context omitted.

I am not saying that it is a better UX, but hashed/versioned blobs on S3 would mostly work depending on tooling integration.

Isn’t that essentially what git lfs is?

I believe so, but with different UX. In almost every case I expect git lfs to be better, but I can see reasons to use more custom flows.

Re: Fossil versus Git

#180

Post by sgbeal »

prepend wrote: post #127
rakoo wrote: post #104

Earlier quoted context omitted.

> 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.

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…

> First, those are bolt-ons and I don’t actually want them tied to the source code management system.

Anecdote: when Richard first proposed the /chat feature in fossil i was highly skeptical about its utility but (as the fossil project's "JS guy") wrote it anyway. Now, almost 3 years later, we've been using chat 24/7 across multiple fossil-hosted projects and can't imagine doing without it. The majority of the sqlite project's coordination happens via fossil's /chat.

Yes, it was bolted on, but it's also become indispensable for us as a feature.

Post reply on HN