It's quite sad to see that so few projects use it. The idea of having everything in one repo, incl. bugs, is just great. I can create new bugs while offline, update bugs while offline, etc. and then just sync everything once I'm back online.
It also has pretty good support for incrementally importing from and exporting to Git: https://blog.nil.im/?79
This is exactly what intrigued me and made me switch to Fossil. I don't want to have my issues, wiki etc. held hostage by some company. And if someone wants to fork it, they should be able to fork it including issues and wiki.
I use fossil mostly as a Customer/Project KB/Documentation tool, when a new project starts i have all the documentation, code snippets/examples in one single file, when the project is finished, i have to give one sqlite.db file over to the customer and that's it. LOVE IT, a really great tool!
> The idea of having everything in one repo, incl. bugs, is just great. I can create new bugs while offline, update bugs while offline, etc. and then just sync everything once I'm back online.
The bug thing I kinda disagree with... or at least I'm skeptical, shall we say. Bugs are solved when the fix has been deployed and verified fixed in production, not when someone commits/pushes/merges a potential fix to the main branch. Sure you can separate the 'bug-X fixed' change to the bug tracker and the code commits, but then what have you gained over just a 'Fixes: X' annotation in the commit msg?
This could be misunderstanding on my part about the intent/process around bug/issue handling in Fossil, so I'd appreciate if you could expand on what you like about and how it works within the larger 'deploy a fix' context.
(I tried Fossil for a bit on a very small scale -- it was pleasant enough, but ultimately Git's network effects win out big time... at least for me.)
It isn't putting your issue tracking into an equivalent of a git repository. It just contains a rather standard-looking issue tracker, along a wiki for documentation, in the same sqlite. And they are distributed/synchronized just like the repository.
If you include the ticket ID e.g. [ticket-id] in the commit's description, the commit will automatically be linked to that ticket. You can view the list of all associated commits with a ticket by clicking the 'Check-ins' menu item on the ticket's page. When an item is closed - the link appears struck-thru.
I dont automatically close tickets on commits - since our workflow is commits get reviewed before closing an item- but it is straight forward to write a small few line script to do this if thats your workflow.
That is only true for projects where you need to deploy. In that case, yeah, you of course can only close the bug once you fixed production. But for normal software development, you can fix the bug in the software and you can update the bug tracker, and then push everything once you're back online.
For example, on a flight, I can look at the bug tracker (since it's part of the clone), pick a bug I want to work on, create a few commits to fix it, then update that bug (set it to closed, reference the commits that fixed it), and then upload it all when the plane landed again.
This is really nice. How have you been hosting this? How well is fossil able to handle the traffic?
I've read so many articles about the advantages of static site generators and serverless implementations for blogs so that they are able to handle traffic and the insane amount of tooling around each of those concepts. It's so great to see a well crafted piece of software being able to take care of all that so seamlessly.
I'm a big fan of fossil personally and use it for all my projects as well as for all the projects in our organization.
A lot of us Fossil users host it on $5 VPSes. It's written in C atop SQLite, so the network is almost always the bottleneck, not the server-side processing speed.
sqlite.org and all of the other repos D. Richard Hipp maintains (Fossil, Pikchr, the separate SQLite docs repo, the forums for Fossil and SQLite...) all run on a $40/month VPS. The page generation time is calculated and displayed at the bottom of non-static pages like this one: https://sqlite.org/src/
This is running on a server with super slow single core performance and slow I/O (Sun Fire T1000 with full disk encryption, giving ~ 2 MB/s for the disk), and yet it feels fast and I've never encountered any performance issues. As long as your repo is not as gigantic as https://pkgsrc.fossil.netbsd.org, you'll be fine, no matter what slow hardware you throw at it.
Thank you for posting a link to your site. It's really nice to see a live demonstration of Fossil. I notice that your page is using https - does Fossil do that or do you have something else in between (nginx, etc) that provides the https?
Another option is running is behind Apache as a CGI, and let Apache handle the HTTPS part. My repos (fossil.wanderinghorse.net) all run as CGIs on a $7/month shared hoster, and have been since 2008, without issues.
- handles large files effectively (build artifacts, 10-40GiBs each, and other binary dependencies)
- partial checkout of the repo/view
- git style operations (have stage area, can stage parts of a file, can stash changes and reapply later, cherry pick)
- can view the history of an individual file (support file relocation)
- access control on individual files, and partial review of the repository (views are "granted" to developers)
- good tooling
- immutable when it makes sense (e.g. you cannot changed a published commit)
- works offline (if possible)
- large mono repo
I evaluated git annex and git lfs, and finally chosen Perforce, mainly for its large file handling, view for each developer and ACL, but the lack of flexibility makes me don't want to commit, and every time I do a merge, I say to myself, "uuh, this again". The other thing it lacks is the "ease of mind", with git, everything is checksummed, if the content changes, it will be noticed by git, with Perforce, you have to tell it you want to edit it. (Not nit-picking on Perforce, I actually think Perforce is a good software, its server runs flawlessly, and have a good p4v (if you don't mind the friction), I think it just lacks good tooling and git style operations)
I enjoy how well-crafted Fossil seems to be; just like SQLite, which a sibling comment also mentioned. I really want to use Fossil, but it would be way too hard for me to not have the index/staging area of Git. [1] For all the software that claims to be 'opinionated', Fossil really is that.
Yes. I use `git add -p` and `git stash -p` all the time and couldn't work without them. Fossil's equivalents appear to let you specify a subset of files to commit / stash, but not individual thunks inside them. [1] [2]
Not to mention the lack of `rebase -i` to clean up local commits.
I'm sympathetic to a lot of what they have to say, but this has always been a sticking point for me:
> Cherry-picks work better with small check-ins
Maybe it's just bad git tooling or me using the tools wrong, but if I need to cherry-pick and there are conflicts, it is always way easier to squash everything down and pick it in one go— if I don't do that, I end up resolving the same conflict over and over as new commits pile in on top of it and meet a conflict-resolved state that they then have a further conflict with.
On personal projects (using git), I use squashing only for small bug fixes like the one you mentioned or when the author of a PR made a big mess of commits (usually because they are a git beginner). Best of both worlds.
I don't see why you would bisect in this situation in the first place. The problem's fixed now, as of commit 5.
But okay, let's take your example as-is: you determine the "good" point is commit 1, and the ...um, other good point is commit 5?
Well, that doesn't work. I guess we have to arbitrarily ignore commit 5 and say commit 4 is bad. A bisect will show that. Then in Fossil, if you visit the /info page for commit 4, it will show its child commit 5 as fixing the problem.
I'm rebasing because the problem from commit #2 isn't fixed. We have a test that shows the problem from commit #2. However commit #4 breaks things in some way that the test we are running can't run. Squashing the commits together fixes this. If commits #4 and #5 were both on a feature branch before merging, squashing would be done by rebasing in the feature branch.
I'm not saying all commits from a feature branch should be squashed to a single commit, but commits like "oops forgot to update header file" or some such are noise.
Rewriting history is about improving the signal-to-noise ratio. You may lose some signal (the Fossil argument against it), but if you lose more noise than signal it may be worth it (the git argument for it).
(Holy shit I didn't realize how long this had gotten.)
I read that page. It's their opinion and I disagree with it.
To be clear of where I'm coming from, I've never used fossil, and I've used git regularly for about 10 years. I only use git from the commandline except that I often use `gitk` to read a branch's commit history or inspect diffs, and I use `kdiff3` for interactive merging when there are conflicts. I actively disable git "integrations" in editors and IDEs.
---
>1.0
Whether other people struggle with rebase or not does not affect me, because I have no problems using it. (This logic also extends to people who complain the entire git CLI is hard to use.)
Now, this might sound like the seasoned C programmer saying "Other people accidentally write UB but I don't, so C is perfectly fine." but there is a difference. UB with C is problematic because it's hard to know it happened, which is why we know the seasoned C programmer might have unknowingly written UB after all. This is not the case with `git rebase` though. Either you do it correctly or you don't, and I can confidently say I do it correctly.
>2.1
This is specifically talking about rebases that move commits onto new parents. Rebase does much more than that. For this particular use case, I agree that some projects even when using git prefer to have merge commits instead of rebased commits, and that's fine. But for projects that do want a linear series of commits, it's good to have the choice. Rebased commits also make it easier to revert just a single commit instead of the whole merge (though of course it's not impossible to revert a single commit of a merged branch either).
>2.2
This whole section is a non-sequitur because indeed the correct pre-rebase diff would indeed be diff(C2, C5) even in the git case. But if you're planning to rebase the code in order to merge it, you need to rebase the code to know what the diff will be.
>3.0
The Windows Vista citation starts off with the (correct) result that lack of communication between engineers of disparate components leads to bugs, but then associates it to mean that these disparate components were being developed in private branches. The cited paper does not talk about branches at all. Indeed, bugs happening because of private branches was not the case then, and is not the case now. The reason those bugs happen is because the engineers of a particular component only work with code of their component.
The "egoless" citation is from a book, so I can't tell if the book specifically says private branches have anything to do with ego or not.
At any rate, this section is fundamentally confused. Making branches public doesn't mean you can't rebase them. If I work on an OSS github project, I would certainly make my WIP code branch public. That doesn't mean I don't want to rebase it right before I send a PR to clean the cruft up.
I think the article author may have read the git advice about not rebasing public branches and thought it meant all non-private branches. It actually means branches other people would want to pull from you and who are not expecting it to be rebased. Single-person development happens in branches only that single person cares about, so whether the branches are private or public makes no difference to that person wanting to be able to rebase them. If a group of people are collaborating and they agree that rebases are going to happen, nothing is wrong with letting them do that. The only problem is with rebasing public branches that people pull from and which those people do not expect to be rebased, like a public repo's `master`.
>4.0
So test each commit then. git doesn't makes it impossible to do that or anything. If anything, ensuring tests pass on each intermediate commit makes `bisect`ing easier in the future.
Also, only using merges means the only tested commit is the merge commit, so you lose the ability to check which commit in the merged branch caused the problem.
See also 7.0
>5.0
`git rebase --ignore-date` will reset the commit date of each rebased commit to the current time.
>6.0
It is correct that commit messages are the only way to associate some of the metadata that Fossil lets you manipulate separately. So (2) and (3) do benefit from Fossil's approach.
(1) and especially (5) happens rarely enough in my experience that it isn't enough justification.
I'm not sure what (4) is referring to by "routine display", but in general the only branches things like `gitk` will show you are the ones you ask for.
>7.0
It also throws away non-valuable garbage. When I'm bisecting a bug, or running a `blame` to figure out what commit added a particular line, I don't need to go through half-commits that got reverted afterwards.
False starts and incorrect approaches can be documented in the commit message or in the code comments.
Also this directly contradicts 4.0 unless we are to assume that only merge commits get tested, and that the user running `blame` does not go deeper than the merge that introduced the line, which has the problem I mentioned in 4.0
>7.1
This section is just a longer reiteration of 7.0, so it has the same rebuttal.
>7.2
This has switched to specifically talking about squash rebases, which is not necessarily the only kind of rebase (and is also not the kind of rebase that the diagram in 2.2 was talking about). I also dislike squashed rebases when merging pulls. But if I have to squash two commits in my WIP branch I absolutely want to be able to.
>7.3
If the checkins are being rebased and are going to be merged without squashing, then each commit has to stand on its own by definition, so of course they should all have individual justifications.
>7.4, 7.5
These are the same as 7.2 and 8.0 below.
>8.0
This appears to be saying that fossil's cherry-pick is not just a wrapper around rebase like git's is. So I agree that (1) and (4) are benefits due to Fossil's approach.
> Windows Vista...components were being developed in private branches.
The claim isn't that Microsoft developers on the Vista project used Git and private branches. The claim is that private branches are another form of siloing which leads to the same sorts of communication problems. They're a way to purposefully hoard code so your fellow developers can't see it. It is exactly what McCarthy was warning about in his "beware a guy in a room" comment; and McCarthy was at Microsoft when he wrote the book cited.
> I can't tell if the book specifically says private branches have anything to do with ego or not.
Weinberger wrote his seminal book in 1972, so probably not. :)
Human psychology hasn't notably changed since 1972. It doesn't matter if you're developing with punched cards or with worldwide Kubernetes clusters, humans are humans.
> Single-person development happens in branches only that single person cares about, so whether the branches are private or public makes no difference to that person
If you're doing single-person development, then the concerns over siloed development don't apply at all.
This section of the document is talking about communication among developers on the same project. If there is no communication on your project, its points are irrelevant, not wrong.
>4.0...So test each commit then.
You're missing the point. If Fossil offered Git-style rebase, the commit would be pushed up to the remote repo you cloned from before you could possibly test it, because of its autosync feature.
> `git rebase --ignore-date` will reset the commit date
How often do you suppose that's done in practice?
The point in the article you're rebutting is that Fossil doesn't make you do that at all, because it doesn't create timewarps or require after-the-fact date rewrites to avoid them.
> I'm not sure what (4) is referring to by "routine display"
It refers to the "fossil amend COMMITID --hide" feature. Affected branches no longer show up in the timeline, in the default branch list, etc., but no info is destroyed. It's just a tag telling the web UI and CLI not to show that branch by default.
> I don't need to go through half-commits that got reverted afterwards.
You're assuming 20/20 foresight. The very nature of software bugs is that you don't know you're committing them at the time, so how can you prospectively know which elements of a commit are good and which bad? You can mitigate it through testing, code review, etc., but Bugs Happen. There are whole companies dedicated to that fact.
The very point of bisect is, "Given this pile of commits between points GOOD and BAD, which one caused the symptom I'm seeing now?" If you knew the answer to that, and thus were able to make the in-advance judgement you suggest, you wouldn't need to do the bisect, because you wouldn't have committed the bug in the first place.
> this directly contradicts 4.0 unless we are to assume that only merge commits get tested
Only if you assume you have 100% test coverage, both in terms of lines of code and functionality. If you are in such a happy position, and you always run your tests before committing, then yes, it is impossible to commit a bug to the repo.
I wanna see that repo, the one without bugs because it has 100% functional-test coverage.
Even SQLite hasn't got that, evidenced by the fact that its test suite continues to change, even for historical features.
> If I have to squash two commits in my WIP branch I absolutely want to be able to.
You're toggling between "have to" and "want to".
And again, you're assuming 20/20 foresight, that you will never want to come back and tease those commits apart again.
The merge point is the proper place to logically "squash" things, not within the WIP branch.
>The claim is that private branches are another form of siloing which leads to the same sorts of communication problems. They're a way to purposefully hoard code so your fellow developers can't see it.
This is such a painfully armchair-psychologist point of view I don't even want to attempt to disprove it.
But consider this: if committing in fossil makes your code immediately visibile to the world, and if we are to assume the people using git want to hide their "imperfect" code in those evil bad private branches (even though, as I wrote in my comment, the whole private-vs-public distinction is irrelevant), one must assume those same people using fossil will also want to hide their "imperfect" code too. Doesn't that mean people using fossil will just commit less frequently?
---
>> Single-person development happens in branches only that single person cares about, so whether the branches are private or public makes no difference to that person
>If you're doing single-person development, then the concerns over siloed development don't apply at all.
>This section of the document is talking about communication among developers on the same project. If there is no communication on your project, its points are irrelevant, not wrong.
Please read the next sentence I wrote right after where you stopped quoting.
---
>>>4.0...So test each commit then.
>You're missing the point. If Fossil offered Git-style rebase, the commit would be pushed up to the remote repo you cloned from before you could possibly test it, because of its autosync feature.
Okay, so it's a fossil-specific problem with a hypothetical fossil-rebase implementation, not a problem with git-rebase, unlike the rest of the page that's pointing out problems with git-rebase. I'm sorry for "missing the point".
---
>> `git rebase --ignore-date` will reset the commit date
>How often do you suppose that's done in practice?
>The point in the article you're rebutting is that Fossil doesn't make you do that at all, because it doesn't create timewarps or require after-the-fact date rewrites to avoid them.
If the repo is on Github and the PR is being merged through its web interface, that is one of the default merge options the repo admins can set.
In other cases, the person doing the merge can remember to use it.
Many options have defaults that can be configured, and this isn't one of them. So either nobody has implemented it yet, or the occurrences of time travel in a linear history hasn't bothered enough people yet. I suspect it's the latter.
---
>> I'm not sure what (4) is referring to by "routine display"
>It refers to the "fossil amend COMMITID --hide" feature. Affected branches no longer show up in the timeline, in the default branch list, etc., but no info is destroyed. It's just a tag telling the web UI and CLI not to show that branch by default.
Okay, so it's not related to rebase then, in git or otherwise.
---
>> I don't need to go through half-commits that got reverted afterwards.
>You're assuming 20/20 foresight. The very nature of software bugs is that you don't know you're committing them at the time, so how can you prospectively know which elements of a commit are good and which bad? You can mitigate it through testing, code review, etc., but Bugs Happen. There are whole companies dedicated to that fact.
I don't think you understood the situation I wrote about. I'm talking about using blame or bisect to go through the history of code that has already been committed, trying to find the source of a line of code or a bug.
>> this directly contradicts 4.0 unless we are to assume that only merge commits get tested
>Only if you assume you have 100% test coverage, both in terms of lines of code and functionality. If you are in such a happy position, and you always run your tests before committing, then yes, it is impossible to commit a bug to the repo.
There is no such assumption in what I wrote.
---
>> If I have to squash two commits in my WIP branch I absolutely want to be able to.
>You're toggling between "have to" and "want to".
The sentence I wrote is both grammatically and semantically correct. It would not be correct to use two "have to"s, nor would it be correct to use two "want to"s.
---
>And again, you're assuming 20/20 foresight, that you will never want to come back and tease those commits apart again.
>The merge point is the proper place to logically "squash" things, not within the WIP branch.
Listen, if I have a commit:
bar the foo
+ foo.bar()
and then another:
derp
- foo.bar()
+ foo.bar();
... then I'm very confident I want to squash them together, thanks. I'm also very confident that when I send a pull request, I want the commit to read
Invoke bar on the foo object before it's baz'd, otherwise foo is in an undefined state.
Fixes #3
+ foo.bar();
> one must assume those same people using fossil will also want to hide their "imperfect" code too
One must not, because if one did, one would be wrong. :)
Go read Weinberger. It's $10 on Kindle right now.
> Please read the next sentence I wrote right after where you stopped quoting.
First, don't assume that because I didn't quote your posting in full that I didn't read it in full. HN is a threaded messaging system: we don't need to fully quote everything just to maintain the flow of the conversation. The history is right there to see on the page.
Second, how does "If a group of people are collaborating and they agree that rebases are going to happen, nothing is wrong with letting them do that," argue against the article in question? That's just a blind assertion, not logical argumentation.
> not a problem with git-rebase,
Sure it is: if rebase commits a breaking change to the blockchain immediately because you weren't able to test it, you have two options: 1. Commit a fix, pushing the broken commit later, potentially breaking bisect and such. 2. Do more rebase squashing and such to fix it in place before pushing it.
Argument 2 is "We need rebase because we used rebase." :)
Fossil's alternative is to not commit anything to the blockchain automatically. If Fossil did have rebase, it would make the changes in the checkout tree only, and you'd have to commit it separately.
The argument is not "Fossil can't have rebase because Git's version is badly considered," it's "Fossil's developers don't want rebase and Git's version is badly considered anyway." Fossil could avoid the design error, but that doesn't make rebase a good idea.
> If the repo is on Github and the PR is being merged through its web interface
...then you're using proprietary software with tremendous lock-in, but okay, if you're willing...
> the merge can remember to use it.
You're really going to insist on that? Commands by the foot, instead of a sensible default?
> it's not related to rebase then, in git or otherwise.
It's an example. The argument we've received multiple times from Git fans is that developers need rebase to make the timeline "clean", but Fossil shows that you don't have to modify history to do that. You just need sufficiently powerful tools that let you preserve history while changing its presentation to the user to suit various needs.
Git's porcelain is showing here.
> derp... - foo.bar() ... + foo.bar();
So you've committed without compiling first, much less running the tests, and your solution is "I need rebase?" No, my friend, you need to compile and run the tests before committing!
>Go read Weinberger. It's $10 on Kindle right now.
No, I think I'll pass. If this conversation is anything to go by, it's not going to be worth my time or my money to read it.
---
>First, don't assume that because I didn't quote your posting in full that I didn't read it in full.
I charitably assumed you didn't read it, as opposed to assuming you read it and ignored it, because it was written specifically to counter the very point you made.
---
>Second, how does "If a group of people are collaborating and they agree that rebases are going to happen, nothing is wrong with letting them do that," argue against the article in question? That's just a blind assertion, not logical argumentation.
It's not a logical argumentation, just like the article in question isn't one. However it is based on real life observation, so it can't really be called "blind".
---
>> not a problem with git-rebase,
>Sure it is: if rebase commits a breaking change to the blockchain immediately
There is no "blockchain" in git. Furthermore, you said:
>>>If Fossil offered Git-style rebase, the commit would be pushed up to the remote repo you cloned from before you could possibly test it, because of its autosync feature.
Therefore this whole situation of "intermediate commits weren't tested" only happens because fossil pushed the commits remotely "before you could possibly test it". This would not be a problem with git because you can run tests on each individual commit before you push them to the remote repo just fine. It also doesn't have anything to do with git-rebase specifically; you can run tests on individual commits regardless of whether they were created by rebasing or not, again before pushing them to the remote repo. Also, the remote repo can enforce that tests must pass on each individual commit, so even if the committer doesn't do it, the server can.
---
>You're really going to insist on that? Commands by the foot, instead of a sensible default?
Again, as I wrote:
>>Many options have defaults that can be configured, and this isn't one of them. So either nobody has implemented it yet, or the occurrences of time travel in a linear history hasn't bothered enough people yet. I suspect it's the latter.
---
>> it's not related to rebase then, in git or otherwise.
>It's an example. The argument we've received multiple times from Git fans is that developers need rebase to make the timeline "clean", but Fossil shows that you don't have to modify history to do that. You just need sufficiently powerful tools that let you preserve history while changing its presentation to the user to suit various needs.
The point in the article was:
>>>4. Cause mistaken or unused branches to be hidden from routine display
Given that it's talking about fossil's "routine display" as opposed to git's, and given that rebasing has nothing to do with hiding "mistaken or unused" branches as it calls them, yes the point is indeed not related to rebase in any way.
---
>So you've committed without compiling first, much less running the tests, and your solution is "I need rebase?" No, my friend, you need to compile and run the tests before committing!
>Maybe you want a better example?
No, I don't think I need a better example, nor do I need to continue this conversation. It's clear to me that fossil requires me to do things in a very different way than I want to. No committing unless it's the final perfect code, because it's the only shot I have at the final thing.
- If I messed up some formatting, I won't be able to fix it in this commit.
- If I feel like some comment could be clearer, or some variable could be named better, I've lost my chance.
- If I added a test that works for me but then I realize it won't work in X situation, I've lost my chance.
- If I'm in the middle of implementing something and just want a nice checkpoint I can `git reset --hard` to while I try something speculative, I can't do that without committing to it forever.
- If I go ahead and make these half-commits anyway, my branch's history is full of incomplete commits. The repo can't possibly enforce running tests on every commit, because everyone will have such incomplete commits in their branches, so at best the repo can only enforce running tests on merge commits. Anyone using `blame` or `bisect` in the future is going to accidentally land on this commit, so they too have to get used to not digging deeper than merge commits. If there's a bug that's tracked to a particular merge commit, the easiest thing to do is just revert the whole merge, rather than try to identify which commit(s) inside the merged branch needs to be reverted.
I'm sure it works out well for the people who use fossil. It's not for me.
Re:
>>Go read Weinberger. It's $10 on Kindle right now.
And the response
>No, I think I'll pass. If this conversation is anything >to go by, it's not going to be worth my time or my money to read it.
Comrade, can I perhaps humbly submit that this is
a very good piece of advice for all of us.
The General Systems Thinking one is great as well.
1971. The Psychology of Computer Programming. Silver Anniversary Edition (1998). ISBN 0-932633-42-0
1975. An Introduction to General Systems Thinking. Silver Anniversary Edition (2001). ISBN 0-932633-4
Agreed. I'd love to have integrated bug-tracking, and some of the other features, but Fossil is also trying to drive particular opinions about version control that are incompatible with how many people want to work.
It's already hard to move people away from a system that has huge network effects. This makes it much harder.
There are several bug tracking systems that store their data inside the repository (and as a result, branch / merge / push / pull automatically) -- including the venerable "vi bugs.txt" system which works surprisingly well from experience.
What fossil brings that those systems don't is indeed the network effect as you pointed out. It's integrated with the web frontend, and is thus used by everyone using fossil and fossil's bug tracking, based on experience with cvstrac, is low ceremony, easy to use and reasonably effective -- even more than "vi bugs.txt" which sets a remarkably low ceremony bar.
Where did you see opinions in that document? It's a technical description of the functional differences between Fossil and Git, explained with Git terminology.
I have great fondness for Fossil, used it a couple of times and wish it were possible to keep using it.
I tried to rally some interest on the mailing list behind separating the working parts from the UI chrome into a 'libfossil', which could be integrated into other programs. The verdict was that D. Richard Hipp doesn't really want to, since it's a classic C monolith where the allocation strategy doesn't make that separation easy. Someone started the job, but had to abandon it due to RSI issues.
I still kinda hope someone bites the bullet, because a "libsqlite for versioning" would be a real boon for application developers. Even for fossil's central use case as a code VCS, the monolithic bundling of everything into one program is a mixed bag.
I run ChiselApp.com to support publicly hosted Fossil repositories.
The architecture behind it is pretty simple, since Fossil is doing all the work and I'm just orchestrating it (although I do allow you to execute arbitrary Tcl scripts as part of it, so there is some work that goes into the sandbox).
Each Fossil repository is its own SQLite database. Additionally, there's an SQLite database which holds ChiselApp.com user information (which is unrelated to Fossil information).
I'm a big fan of Fossil, but I've sadly not used it in a while for new projects, as when stuff has to go on gitlab or github it is just too inconvenient.
Even though one-way pushes to github/gitlab via --fast-export / --fast-import are relatively painless, going the other way for contributions is still not easy because of rebase issues, etc, at least to my knowledge.
Whoa. Many, many years ago I started idly hacking on a similar project with similar ideas and an identical name. I've always intended to return to it in my Copious Spare Time, which of course means I never did and probably never will.
When I started exploring this I registered the gitbug.org domain - would you be interested in using it for your project?
Haha, that's awesome. It's interaction like these (and pretty much this whole thread) that make me think that there is value in this idea. It just has to reach some completion with a good UX ...
I have a bunch of git-bug.tld domains so I guess I'm all set already?
I'd be curious to see your project. Maybe there is a good idea in there? In any case, you are very welcome to join the party.
I wanted to use Fossil but the division between what you do in CLI and what you do in the web UI was too arbitrary. I wanted to edit the wiki in vim, for example. Now I don’t care anymore and just use Git and GitHub
Yeah it's a bit bifurcated. Internally there's a lot of coupling -- HTML embedded directly in the C code and whatnot. This could be resolved if tools could be built on top of fossil, but the CLI code uses `exit` everywhere which makes it impossible to use as a library. I think they made an incomplete attempt at a JSON API, but what you really need is a proper linkable library like libgit2.
About 3 years back I was having a discussion with my CTO and he was mentioning why he likes `hg` instead of `git` and that how he uses hg-git bridge to handle git repositories and all. But still he supported the git as the organization wide adopted SCM tooling. Reason being that when we have to choose a tooling which needs to be used by a lot of people in organization then we also need to consider about the learning curve and adoption of a tool. Git is already a default tooling and so many engineers are already familiar with it that choosing it came natural. Moreover, the SCM use-cases for us were mostly the regular standard one.
Over time, I have started to think in terms of innovation tokens [1]. You cannot choose all the new technologies all the time and you have to measure how many innovation tokens would you like to spend on what.
Hg's developer ergonomics are just way nicer than git. I tried the hg-git bridge at my current job, but the bridge becomes unusably slow for large git repos.
Aside from standard version control uses, I eventually realized that the tickets database is just a regular sqlite database that lets you edit the schema and query any way you like. What's really cool is that it's version controlled. You can put any information you want into the tickets database and then pull changes like any other repo. You can view the timeline to see all the changes you've made to the database over time.
I would "Join the wait list" but it just opens a page with something my browser blocks immediately because it side-loads some frame from google.
A simple HTML form to summit an email really cant be that hard that it needs to be outsourced to google.
Apologies. Launched just 2 days ago as a static site on Netlify. Will add a JAMstack-based form once our api backend server is up and running. Google Forms was a quick and dirty solution that let us deploy something now. Fossil on HN is rare so I prematurely jumped at the chance of a mention.
Can anyone give a conceptual model breakdown of the data model of fossil vs git and trade offs? I’ve been quite interested in these types of structures. I need to play more with them.
The first item on "why sqlite does not use git" asking for a timeline view. That looks almost exactly what "gitk" shows, which was builtin to git before github or gitlab existed.
A quick scan of the other items are all more-or-less true so it's a shame it leads with that.
It isn't shipped on macOS, and the Homebrew version of Git has it packaged separately.
I fired it up on a Git export of a Fossil repo here, and it's missing features of Fossil's web UI timeline view:
1. Cherrypick markers
2. Diff arbitrary versions (it shows only diff from previous)
3. Branch coloring
4. Hyperlinks to produce new timeline views: click author to get list of commits by that author, click timestamp to get a new timeline surrounding that point in time, etc....
5. Integration with other web UI features. For instance, you can create a Fossil wiki article attached to a commit from Fossil UI, but you can't attach a GitHub wiki article to a Git commit from gitk.
For another, Fossil has a feature to produce zip and tarball downloads of particular versions, which have links in the commit info page, which means visitors to your project don't need to clone the whole thing and roll it back to that version manually to get a single version. That's integrated into the Fossil web UI timeline: click a version, click Zip, done.
6. A modern browser fits its platform and offers more UI affordances than the mid-1990s Motif-inspired Tk. (Better copy/paste behavior, font rendering, zooming, native controls, etc.) Web UIs get a lot of angst these days, but like them or not, they're native citizens of the host platform these days in a way that Tk is not.
> It isn't shipped on macOS, and the Homebrew version of Git has it packaged separately.
That's a bit like saying python doesn't ship with a GUI because ubuntu split tkinter out; projects can't control what downstream does, and the complaint from the article was that they didn't want a second dependency; gitk is part of the git project so it's a single dependency just as much as relying on fast-import would be.
Yes, I suspect fossil's timeline is better than gitk, particularly since gitk has changed almost not at all in the past decade. However the complaint was not that gitk was worse than timeline, it was that there was no tool even slightly like it in git (and then the github "network graph" was not part of git, and worse than the Fossil timeline; that particular point makes me think gitk was never considered).
As a side note, #3 isn't possible in git because commits don't belong to branches, but that's addressed in a different point from the article in question.
> Fossil also supports bug tracking, wiki, forum, and technotes
That sounds great, but I'm scared of checking these features out because I'm currently looking at the quick start guide[0] and am immediately put off by how awful the CSS is. Formatting running text such that a single line can be ~500 characters wide[1] results in very low readability. There's a difference between ‘themeable’ and ‘configuring a custom theme is mandatory because the default option makes you feel sick’.
In case someone working on Fossil sees this: I just bookmarked the site because the project seems very attractive in most other respects. I hope that when I eventually re-visit that link, I'll be able to go on a significantly deeper dive. A somewhat sane style sheet would certainly help.
I agree this can be annoying when you have really large windows, but personally I don't mind it. I don't think it's hard to resize a window, and I _have_ been frustrated when sites (like the new Reddit) force a narrow window when sometimes you need to see more at once.
I think the complaint was that lines aren't capped somewhere at 70-80 characters but rather fill the entire remaining space in the viewport which can make the text hard to read.
I see where you're coming from but resizing the browser to your preferred text width would mean decreasing the space for elements like the tab bar or other "not-in-body" UI elements even though there's still screen space available. I'm not sure that's something most people would want.
Not to mention some sites have things like side bars, images or other UI elements that make them more comfortable to user with larger viewports so you'd resize your browser often when you switch tabs.
It would be useful if sites could specify a "body" element that could be resized and aligned however the user wishes without affecting other parts of the site or the browser UI.
Right but then it becomes a mess to find anything if you have to look in multiple tab bars or you have a lot of windows which could also become hard to manage. My point is, while your approach works for you it's probably not useful or intuitive to enough people to justify designing your website around it.
Yes. I'm not a stickler for 70—80 characters; IMHO the ~200 character lines on HN are excessive, but I can cope. You know, Postel's law: be conservative in what you do, be liberal in what you accept from others.
I took the aforementioned screenshot on a huge display to illustrate the issue more clearly, but on a garden-variety 1920×1080 monitor — stock Firefox, no extensions that would affect rendering — Fossil wiki's text formatting is still objectively bad.
I use Fossil myself; it is much less confusing than git. (You can even import/export git if you need to mirror it on Github or if another user prefers to use git instead of Fossil.) However, I do not use the forum feature since I prefer to use NNTP for that instead (although Fossil does provide some of the same benefits, and I might use it if it could be used together with NNTP). I do use the Fossil wiki though. It is indeed good that the bug report system can be used without an internet connection, and also that the repository is just a SQLite database file; there are clear benefits to this.
fossil has much better command line experience than git. I used this in the past for my solo project but abandoned it because virtually everyone uses git these days.
Reading through some of the articles linked in the comments, I'm very hesitant to use something whose creator is so opinionated and vocally against another piece of software. Maybe its just the style of writing, and isn't actually reflected in Fossil's development, but this kind of attitude doesn't inspire confidence.
It's more that "why don't you use Github for sqlite" comes up six times a day, so at a certain point you have to explain why you use your own version control system. A lot of developers today know nothing other than Git and assume anything else is wrong by default.
Not only that, but they spam the Fossil forum with request to make Fossil more like Git, even if they don't personally use Fossil, because they seem to be unable to accept the fact that Fossil exists and drh has making the decisions that he thought best for the software.
It's quite sad to see that so few projects use it. The idea of having everything in one repo, incl. bugs, is just great. I can create new bugs while offline, update bugs while offline, etc. and then just sync everything once I'm back online.
It also has pretty good support for incrementally importing from and exporting to Git: https://blog.nil.im/?79