[jchw]

Hg actually does go beyond Git in many areas; I did outline a few but my favorites are the improved commit model (stages, natural branching, rewrite tracking,) the commands Git doesn’t have (absorb, evolve,) and the extensibility (see Facebook extensions.)

Sure, the model is similar and Fossil is different. But that is kind of an important note. If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems.

In most setups, the bug tracker and source control are separate, but that doesn’t mean you can’t get bugtracking alongside code either, GitLab provides everything from bugtracking to CI to deploying stuff to Kubernetes.

Not to say Fossil isn’t cool or doesn’t have its place, but if I disagree with the philosophy (and I do, fundamentally,) then I don’t feel like I lose much using alternative software suites.

[darkpuma]

> If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems.

Or Fossil provides a superset of the others. Like comparing a corkscrew, which only opens bottles of wine, to a swiss army knife that has a corkscrew. They both solve the same problem, but one of them also solves other problems and is generally a more useful tool to keep around in your pocket.

The world didn't lose much with Hg losing to git. But with Fossil losing, we lost a great deal. As a consequence we have a world where people feel locked into the proprietary bug trackers their git host provides. Had Hg prevailed, that situation would be no different. The only way the world would be different if Hg had prevailed would be fewer posts on HN whining about git's interface being obtuse. Not really a substantially different reality, is it?

[avar]

If you care about distributed bug tracking you might be interested in, or want to contribute to git-bug: https://github.com/MichaelMure/git-bug

It's aiming to create a fossil-like distributed bugtracker on top of git, with bidirectional importing from e.g. github's and gitlab's APIs.

[jchw]

I don’t think people feel locked into proprietary bug tracking, they just choose it out of convenience. You can export data from Github or Gitlab.

I mean hell, trac and redmine have been around forever now. Is an open source wiki+bugtracker that revolutionary?

My best guess is that there’s some benefit of merging the source control in, but I’m not sure; it’s not like other environments can’t provide integrated bug tracking.

[darkpuma]

> "You can export data from Github or Gitlab."

And then do what with it, import it into your own bugzilla instance? Have you ever tried that? It's a nightmare.

[jchw]

To be fair, Bugzilla is a nightmare by default.

At my previous org I imported our entire Github org into Gitlab EE. Don’t remember much pain, seemed pretty easy to me.

[rswail]

From my perspective, your last sentence is the wrong way around. It's not merging the source control into bug tracking, it's merging bug tracking into distributed source control.

[jacobush]

I used Fossil but it became very very slow when the repo size crawled near a gigabyte.

[rswail]

The issue that Fossil addresses from my perspective is the integration of bug/issue tracking and the VCS. The trouble with using Git{hub,lab} or other issue tracking is that the issue control isn't distributed in the same way as the source control is.

I want to be able to do a code review, deal with an issue, make changes to source, test etc offline/on a branch and then push all of the changes/impacts (source, issue, comments etc) for distribution to other developers.