Hacker News Reader

Hacker News

Comment by bradley13 | Hacker News Reader

Full thread

bradley13

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

View on HN

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 these are crazy advanced or complex features.

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.

Just a minor example that irritated me today: try to look at a graph of past commits. In GitLab, it is nicely presented. In GitHub, it is nearly useless.

> Well, do you use GitHub or an equivalent?

Not sure how that's relevant, but I have ~150 repos locally and less than 10 on github. I also like the unix philosophy of having tools that do one thing and do it well.

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

Most popular Linux distros include a whole lot more than just a stripped down kernel.

Exactly, they include other programs. They don't ship a kernel that includes a music player.

That's a meaningless distribution as far as most OS uses are concerned.

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.

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.

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.

Okay? Some of us might want to.

As the git people love parroting of its myriad kitchen sink commands, "if you don't like it you don't have to use it".

I'd rather have a single integrated tool than the shopping list of "just use X and Y and Z" people are prescribing in this thread for getting the so-called git ""ecosystem"" ""working"".

Not that I'll necessarily use all the added features; but the ones I do want being integrated is absolutely relevant to my interests.

Yeah, I really want to solve merge conflicts on tickets.

Versioning/distributing tickets is indeed useful; but can't this be "implemented" in git already, by defining a file-based format (think, issue/$YYYYMMDDHHMMSS-$title.md, but the variants are endless), and versioning those files?

A first drawback I can think of is that this would probably require an additional layer for non-tech people. I haven't had the opportunity to use Fossil, so I am clueless regarding the kind of UI they propose, but I wouldn't be surprised that they actually solve this, considering the extensive list of features.

Well the article does say:

> These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design

Ah, I probably wasn't clear enough: my point was that the core of the feature (i.e. omitting non-tech users) can be implemented so cheaply that it seems a bit superfluous to require a built-in implementation.

However, Fossil's documentation[0] has some answers:

  Some other distributed bug-tracking systems store tickets as files within the source tree and thereby leverage the syncing and merging capabilities of the versioning system to sync and merge tickets. This approach is rejected in fossil for three reasons:

  1. Check-ins in fossil are immutable. So if tickets were part of the check-in, then there would be no way to add new tickets to a check-in as new bugs are discovered.

  2. Any project of reasonable size and complexity will generate thousands and thousands of tickets, and we do not want all those ticket files cluttering the source tree. 
 
  3. We want tickets to be managed from the web interface and to have a permission system that is distinct from check-in permissions. In other words, we do not want to restrict the creation and editing of tickets to developers with check-in privileges and an installed copy of the fossil executable. Casual passers-by on the internet should be permitted to create tickets.

Point 3. indeed requires additional software;

Point 2. could be solved by storing the tickets in a distinct repository.

Regarding point 1., as far as I understand, a check-in is an atomic series of modifications to the repository database, so it seems there is a strong correlation between the tickets and the "commits"? If so, why not, but I'm not sure why this is necessary either.

[0]: https://www.fossil-scm.org/home/doc/trunk/www/bugtheory.wiki

I like the “separation of powers” between git and GitHub functions (and gitlab).

It’s nice to be able to start git repos locally and only push to GitHub when I need to.

I also use gitlab quite a bit and it’s so clean to be able to pull from gitlab and push to GitHub, or vice versa. I don’t need any utilities, I don’t need any special workflows.

Git is sort of like a protocol with gitlab, GitHub, and others built on top.

If GitHub owned git then it would be so tightly coupled and suck.

I don’t think a VCS demands features of chat and the others. And the evidence provided by the millions of users seems to support that.

It’s not that chat and wiki are super complicated, it’s just more stuff. Implementing an alarm clock isn’t complicated either, should VCMs have alarm clocks as well?

It's a good list actually, and shows what fossil devs value. Which is more often than not something I don't value highly.

I’m of two minds. I like the unix philosophy, and I feel like an all in one tool (probably written in C) is just a bigger attack vector. But I also like that there are alternatives to the git monoculture. I think the focus on convenience for common dev team functions is rather nice.

> I don't want my version control system to be a wiki. Or a chat app, or any of that.

Then just don't use those features. There is no performance price for it.

One of the nice things about Fossil having a ticket database is that you can use it as a distributed, version-controlled SQLite database to store anything. You can even use it as a JSON database if you want. And the forum, well, it's lovely to have it there even if you rarely use it. Because sometimes if you're working with someone else it comes in handy - some conversations really should be kept with the code.

Then don't use those features. Do you know how many commands Git has specifically for formatting/sending/applying patches via email?

That's the thing, fossil isn't merely a VCS, it's a full dev collaboration environment and includes all that is needed

I agree. But tickets... maybe. Issues feel integral to a project. -- it's weird they depend on what server you put stuff on.

It's also subtly useful to have them be actually on the disk when you need them.

Well, GitHub wiki is integrated too.

https://docs.github.com/en/communities/documenting-your-proj...

github isn't git

GitHub is not git. GitHub’s wiki is actually a whole standalone repository

GitHub is not Git.

Reply on news.ycombinator.com