Fossil – Next Generation
fossil-scm.org
fossil-scm.org
The other day, I had 60 minutes of free time between events and so I brainstormed a few ideas for improving Fossil while sitting in a Starbucks, and those unedited, spur-of-the-moment notes trigger a big discussion on HN... Yikes! I do appreciate the feedback. Seriously. Your comments are very, very helpful. But let's not attach too much weight to my musings over coffee.
Should I interpret the response here to mean that there is latent demand for a new-and-improved VCS in the world. Does this mean that Git is ripe for disruption?
Some Issues I Have With Git
(1) A Git repository is a pile-of-files and/or a bespoke key/value store (packfiles). The format of the repository is underdocumented. (Proof sketch: try to write a utility that reads content out of a git repository without first studying the git source code.) The repository format is also brittle, as evidenced by the difficulty the Git developers have had trying to add support for hash algorithms other than SHA1.
(2) The key/value design of Git limits the information you can extract from the repository. Example: It is difficult to find the descendants of a check-in in Git - so difficulty that nobody ever does it. You can find ancestors easily, but finding all the descendants of a check-in is very hard. In addition to depriving the user of useful information, the inability to find descendants of a check-in leads directly to the "disconnected head" problem. That one deficiency is a show-stopper for me. And this is but one example of the limitations imposed by the key/value design of Git.
(3) For people who don't want to put their trust in GitHub, setting up a Git server is way too difficult.
(4) Git requires the user to remember too much state information. Git users should be cognizant of (a) the current check-out, (b) the "index" or staging area, (c) the local head, (d) the local copy of the remote head, and (e) the actual remote head. The more mental power users must to devote to keeping track of Git, the less there is available to work on their own code.
(5) Git only allows one check-out per repository. (I am told there are resent extensions to git to try to address this deficiency, but I am also told they do not work very well.)
(6) Git does not do a good job of remembering branch history. In particular, branches are unnamed in Git.
(7) Git is for file versioning only. Other important project information, such as bug tracking, must be handled separately.
Fossil is an effort to address the problems above. I do not claim that Fossil is perfect, just that it is better than Git. I am keen to make Fossil even better. Your feedback is appreciated.
I am not as familiar with Fossil, but it seems that one use case Fossil may be well positioned to address, is the storage and revision of data sets along with data analyses.
For people working with any significant quantity of data, git was a backslide as compared to svn. For people wanting to do reproducible research, git does a great job storing the code, but the data assets must be stored out-of-band if they aren’t tiny.
Any thoughts as to how Fossil might or might not address that use case?
EDIT: I should add that, in addition to data uses, I’ve heard tell that git isn’t great for storing art assets along with code (e.g. video game development)
I was very active in the Mercurial community for a long time, and I'm still using it for personal stuff today. Mercurial solves issues 1, 2, 4, 5, and 6 in your list. I'm mentioning that for only one reason:
That was not enough.
My personal theory on why this happened largely centers around network effects. Git got big in Ruby at the same time GitHub came into existence, and I think that drove the adoption as much as anything. Ignoring whether people here feel that Git was better or not, the simple fact is that it did not matter: GitHub used Git, and the community used GitHub, so you used Git. The network effects in that kind of situation can be really hard to defeat. And while it's possible that solving items 3 and 7 will make the difference, I don't think that'll do the trick unless you can come up with a strong way to defeat GitHub's (and Git's) incumbent network effects.
This is interesting. In my using git I haven't ever needed to look at descendants. Perhaps that's just because the limitation is deeply established in my mind (git is really the only VCS I've used). How might this information be helpful in normal usage?
That's my theory, too. I never needed to run "bisect" until I had the capability to do so. Now I can't seem to live without it.
One thing I think would be a killer feature (though I'm not even sure if it's possible):
Supporting large binary assets in the repo without slowly down terribly.
I'm pretty sure that would be enough to get many people to switch. From there, you might see a network effect as people that didn't even care about that grew to like your other points of improvement, and eventually Fossil could overthrow git and becoming the reigning VC champion.
My 2¢. ;-)
(1) Good UX -- steal more from Mercurial here. No "index" or staging area by default, or at least a way to disable it. Being smoother about branch handling between local and remotes would also help significantly IMO.
(2) Network protocol and probably on-disk compatibility with Git and maybe Mercurial -- essential to gaining adoption.
(3) Better support for binary files, perhaps through using a modern content-defined chunking mechanism like FastCDC.
(4) Good support for narrow and shallow clones, maybe even making new clones (somewhat) shallow by default.
(5) Write it in Rust with a good modular architecture: good (including startup) performance, safe/robust and easier to reuse key parts (see also Facebook's Mercurial server stuff in Rust). The lack of a coherent/reusable architecture in Git has also been a key reason AFAICT that Git and Facebook are investing in Mercurial-based tooling.
(6) Use the inotify/FSEvents/whatever the windows equivalent is APIs to keep a daemon and have much faster status responses plus potentially record every change to the files on-disk -- sort of like Git's reflog, on steroids. Could also do smart build system integration here?
(7) Better support for very large trees (a la bup's midx extension to Git's storage format). It should really support Google/Facebook monorepo scale.
I have thought about starting something like this -- but I'm not sure this is the kind of thing where crowdfunding would afford me to build it out; and also not sure the big tech players would be willing to fund something like this (if they are, let me know though!).
I think the items that really have potential to address pain-points & be killer-features that motivate people to move beyond git will are (3) and (7) (big files and big trees).
The rest are probably nice, but are more incremental improvements than something that's going to justify the huge leaving-the-standard-platform cost.
Side note:
Regarding good UX, I very much agree that git's command line is insane, and makes it unnecessarily hard for people to understand.
However, I would disagree that the staging area is a bad idea! It's one of my favorite git features. I think it's just git's extremely confusing command-line terminology and shitty information display that it seem confusing.
As a small piece of evidence in favor of this view, I'll say that I recently introduced a tech artist to git using the (extremely good!) GitUp app. He had no problem picking it up right away, including staging, committing, pushing, making branches & merging.
I think this is because the excellent GitUp UI represents the concepts in such a nice visual way that they become very clear.
Fossil avoids all that, and is, of course, orders of magnitude more manageable than Git. For years, I have been using it for all sorts of personal record-keeping. All sorts - code, yes, but also notes and manuscripts and sketches and what have you. Super-handy tool, with baked-in wiki and ticketing, and everything neatly packed in a single SQLite-file.
Mind you, the new encrypted Git-service in Keybase is sitting there, calling my name.
There are other hosted git services, and it also not super hard to set up a repo manually, on a server or even locally.
I agree Git may be too complex for some people or projects, and Fossil can fit better there. But Github is not the issue, as it can easily be avoided.
But once in a while, we get stuck with a de facto standard that's actually quite good in its category.
I happen to thing git is one of those. It took a while to get there, we had to suffer through decades of crappy source control systems until we eventually stumbled upon a good one.
I'm happy with git. It has a terrible UI but beyond that, it's been an incredible force for progress not just in the open source world but increasingly inside companies as well. It fosters team work, encourages external contributions and once you've gotten used to its arcane flow, it enables all these aspects in pretty efficient ways.
I'm happy with git. You should be too.
And you should also be wary of making claims such as "Fossil is orders of magnitude more manageable than git". The burden of proof is on Fossil and beating git is a tall order.
Be careful guthub is nice but a proprietary monolith -> but git is nice. Hm ok but gitlab.
The well-documented shittyness of the git user experience was the key to its success because it forced the creation of shiny wrappers and integrations to hide the abomination within. And this combination of gloss and peer pressure now manages to convince people that git is "good".
Worse is better indeed...
I do think the time is just about right for someone to start a new generation that has compatibility with Git but provides a better user experience. Also in this category, see the Breezy effort that some old-time Bazaar hackers have started:
> I'm happy with git. You should be too.
This is the only part of your comment I don't agree with. Just because you (and me too) are happy with git, that doesn't mean we should be advising other people to be happy with them. Let everybody decide for themselves what they should be happy about and if by some chance their unhappiness produces something even better, we all win again.
You can get this, more or less, with the combination of using `git rebase` and `git merge --no-ff`.
Bad: squashing commits that have been pushed. Very bad. Not just because it rewrites history but because it's going to cause headaches to other people.
Good: squashing commits in your own local branch before pushing to origin. In my opinion, this is not just good, it's excellent. Nobody on my team needs to know how many micro commits or dead ends and backtracks I've gone through before I reached the current shape of the code I'm about to push. I love squashing in this situation so I can rearrange and make the commit more pretty before it becomes public.
On top of that, I'd argue that this kind of commit squashing contributes to making better commit logs.
1. You can run `bzr log` on a git repository (with the bzr-git plugin). Hence it's a UI issue.
2. That operation still takes O(history size) time, because git repositories lack the necessary metadata to make the operation fast (hence: "largely" a UI issue).
I agree that git is pretty nice, and ubiquity is an important feature. For example, if you choose git you'll find loads of tooling, documentation, infrastructure, etc. that supports it. If you encounter a problem using it, there's almost certainly a fix or a detailed "won't fix" explanation in a blog post or on StackOverflow.
> I'm happy with git. You should be too.
Making git a de facto standard has won a VCS battle, but not the war; there's no reason to be complacent.
It's fine to not care too much about VCS: just test the waters every now and again to make a quick cost/benefit assessment of the options; right now, that probably says "just use git". The majority of users should take this approach, and spend their time and effort on improving other things they care more about.
Yet it's also fine to still care about VCS, try to invent or improve things, add more tooling or integrations for whatever non-standard system, and promote those things in order to nudge those cost/benefit analyses a little. If something becomes compelling enough, a feedback loop could make it the new de facto standard.
Whilst I'm not particularly excited by Fossil, I am by other VCS ideas like the "patch theory" used by Darcs ( http://darcs.net ). A major problem with Darcs is poor time-complexity, but enough people cared about the idea to make Pijul ( https://pijul.org ) which doesn't have this problem.
Does that make Pijul better than git? No, not least because of the project's immaturity and lack of tooling, integration, etc. Yet it nudges the cost/benefit a little, which might encourage more of those who care about VCS (say, those writing integration plugins) to support it, which nudges the cost/benefit a little more, and so on :)
'Orders of magnitude' refers to a) the built-in web-interface and the bundled tools, b) the self-contained and super-easily compiled executable, and c) the one-file repository, consistency guaranteed, which I can stuff in my pocket and do with as I please.
Git is generally not very suitable for new features, because the repository format is very restrictive and has no room for adding new metadata (it's not impossible, but it's always going to be a hack).
Most actual progress in version control has happened in systems other than Git, both open source and commercial (what Git has gotten is a lot more polish and ecosystem integration).
My general criticism of Git isn't that it's bad, but that it's the lowest common denominator of modern version control and has resulted in technology being locked in to yesterday's state. At the same time, it's awfully complicated for how relatively basic its feature set is. It is not a bad tool, but it's not a particularly attractive one, either.
Also:
> It took a while to get there, we had to suffer through decades of crappy source control systems until we eventually stumbled upon a good one.
Umm, what? Git wasn't the first attempt at improving upon CVS or SVN, and was arguably in some aspects worse than some of its predecessors (it often had higher implementation quality, but in terms of features it was also often a step backwards). I think lots of people are not familiar with PRCS (including the specced-out, but never implemented PRCS2), GNU arch, Monotone, or Darcs, not counting commercial or more esoteric ones.
This feature was supported many years before that via a separate script.
That’s not the point of GP post. In fossil for example, one can have multiple checkouts of a single repository (on a single computer by the same person) without fear this will lead to data loss. I don’t think this was suggested as a backup strategy, just a workflow feature.
At the same time I can't claim it is guaranteed to be "no data loss" because I didn't review all the code. If you are strongly concerned about data loss you would probably use backups, _regardless_ if you use git, fossil etc.
Agree strongly.
The simplest example is when the only live reference to a commit is a detached HEAD. Because HEAD is duplicated per workdir, other workdirs do not know about HEAD, and if it doesn't refer to an actual ref, it's subject to garbage collection.
This isn't much of a risk if there's constant ongoing work (because then the GC grace period and the reflog will typically save you), but it can be a problem if you're dealing with a branch that sees only intermittent work.
Even without that, it's pretty easy to destroy graph ancestry (which is not actual repository content, but still fairly important metadata). Example:
set -e
git init g
cd g
echo 1 >foo
git add foo
git commit -m test
cd ..
sh git-new-workdir g g2
cd g2
git checkout -b foo
echo 2 >foo
git commit -a -m foo
git branch -d master
cd ../g
echo 3 >foo
git commit -a -m master
git log --graph --all
The underlying problem is that there are some important invariants that Git needs to maintain to ensure repository integrity in the presence of mutable history, and if part of the information is held in a place that it does not know about, it may not be able to maintain those invariants.
There's a reason why `git worktree` goes to a lot more effort to prevent such scenarios by registering worktrees with the repo and why `git worktree lock` is still needed.
Also, on Windows it is just a single, statically-linked executable, so "installing" it is as simple as copying the executable into a folder that is in your %PATH%.
I am sure Git supports a lot of advanced use cases that Fossil does not, but for my needs, it is pretty close to perfect.
One feature I do miss the ability to copy a file along with its version history up to that point. It is not super important, but sometimes it would be helpful if one could see that a given file started its life as a "fork" of another file.
In a lot of ways fossil is pretty stable and hasn't seen sweeping changes in a while. It hasn't really needed them, but I'm glad that it's getting some renewed interest
We have a FAQ entry for that:
That's certainly a good reason to stay away from github but a terrible reason to roll your own infrastructure.
How about using a hosted gitlab instance? It's been progressing extremely quickly and even has features that github doesn't have yet. You get the best of both worlds: git and being your own master.
> I am much more efficient using my mail client (mutt) and text editor (emacs) than a web browser form.
That's a surprisingly myopic view point.
Of course, you are entitled to your preferences but if you take your project seriously, you need to realize that the choice of an arcane bug tracking system means that most users will simply never file bugs for your project, let alone fix them and then update your bug tracking system.
You are most likely facing a huge opportunity cost here and you might never have realized it, even if you might be tempted to answer that you have received bugs against your project. Think again: how many users were about to and then just gave up when they saw you use non standard tools?
This is really a simple choice: whose life are you trying to make easier, yours or your users'?
But the underlying claim is true.
Filing a bug report takes effort, including: reproducing the bug, doing my best to isolate the circumstances in which it occurs, checking for existing reports of the same issue, and (if none are found) writing up as clear a report as possible. It creates a social obligation to follow up on responses from the maintainers, especially if I want to encourage them to pay attention and fix the bug. In particular, that may involve delving into the design of the code and figuring out the true nature of the problem, or what a proper fix would look like - which is almost invariably more complicated than it initially appears. And for all that, it generally comes with no guarantee that the bug will be fixed or even the report looked at. Even if the bug is fixed, it usually won’t be fixed quickly enough to obviate the need for me to work around it or deal with it somehow. In other words, filing the report probably won’t help me much; I do it more for the benefit of anyone else who runs into the same problem in the future.
I get a sense of satisfaction from filing good bug reports, but it’s enough effort,for little gain, that it takes very little to make me lose interest and go spend time on something else instead. In the case of build2, I’m not even unfamiliar with mailing lists - I run a mailman instance myself - but I don’t regularly contribute to any projects that handle bug reports over email, so it would be an unfamiliar process, which is more than enough of an ‘obstacle’. I’d also get mildly stressed out thinking about the proper etiquette for mailing lists (should there be a greeting?), although that’s more of a personal quirk. And then there are the “posting guidelines”…
Other people may be less socially inhibited than me, but then, a lot of people have much less experience with mailing lists than me (e.g., for many, exactly zero).
Thus, regardless of what ought to be true or what’s reasonable or fair to maintainers, in practice, I strongly suspect that any given bug in build2 has a lower chance of being reported than it would have with a more GitHub-like process. (That may or may not actually equate to actual missed bug reports, because the community seems to be small enough to make for a low sample size.)
I am really excited to see the new avatar of fossil.
Perhaps we should build something like gnu social (or diaspora, but not as bad) for code projects, or build on existing distributed social networks.
There is an issue on GitLab to enable federated pull requests and I believe Gogs/Gitea community is working on getting some sort of standard figured out if I'm not mistaken.
But I’m not sure I agree with the conclusion here You do need the network effect if you want git gone. GitHub is just easy enough to cross reference bugs in other repositories your project depends on.
The web UI is adequate and works really well. Git does not come with a web UI of its own and the CLI is quite arcane compared to fossil.
We've been happily using fossil for at least three or four years. It gets the job done without getting in the way.
I'd really like to use fossil-ng on git and hg repos. That way I don't have to touch git ever again.
https://www.fossil-scm.org/index.html/timeline?y=ci Adequate for what? That is just a mess of unimportant info.
That screen contains all and only the information I want to see. (No surprise, since I wrote that screen.) I would very much like to read more details from Xwattt about what he (or she) finds messy, unimportant, and inadequate about the timeline view of Fossil and to perhaps see examples of better presentations of development history.
I wonder if Xwattt has tried clicking on two of the check-in circles in the graph from the link above, in order to get a diff between the two selected check-ins? Is that information not useful?
What of the filtering options in the sub-menu? Is clicking on "Files" to see all the individual files changes in each check-in not helpful?
Is clicking on a branch-name tag to see a timeline of just that one branch not something that other people ever want to do?
Seriously - I'm not trolling here. I honestly what to grok what it is that Xwattt finds inadequate about the Fossil web interface, as understanding this will help to make the interface better.
That would be the best way to understand what people are used to, and consequently what they will expect to see (or not see).
If the reply is, "fossil is meant to be different," then of course you have your answer; it shows you what you care about, not what people who are accustomed to other systems care about.
I find fossil's history graph more useful than github's commits view which is basically just a git log and only lists one branch at once. In fossil I can see all checkins on all branches simultaneously. If I want to see a signle branch I click on it. If I want to see a diff, I click on the checkin link.
http://noisydecentgraphics.typepad.com/design/images/2008/03...
> examples of better presentations
Here it is - http://github.com/
> Is that information not useful?
Sure, all information useful, but presentation and usability of fossil ui is near zero. It looks like a programmer without any aesthetic taste just throw all information in random places on screen just to fill it. While UX designers polishes every checkbox, padding and font size. For example - why unreadable commit ids occupy so much space on the screen? When I open timeline - I want to read commit descriptions first, and only after that I may be interested in some commit id. I'm opening github timeline and I'm focused on commit descriptions, but fossil timeline accents me on useless commit ids!
> I'm not trolling here
Me too. I bet 99% of Github success is a good UX - but it is very difficult for programmer to understand it.
Look and feel. I have tried different UI themes - github and stackoverflowesque (so-skin.txt) are the most successful in getting buys in - but out of the box fossil, tends not to get a great initial response and it is suprising how many people just stop there.
Fossil timeline graph is different from Github commit view - which is the main tool many of devs I work have only used. I much much prefer Fossil graph view to Github commits I find it a lot more helpful, but others do not see it this way. This can usually be quickly solves with some on boarding training, but it is a small initial barrier friction point to adoption.
Tickets and timeline - Actual user feedback said while trying to get a colleague to use Fossil -" In tickets and timeline - Whats this weird jumble of letters i have to click on - why can I not click on the ticket title?" While obliviously all tickets need a unique identifier - do i need to look at it all the time, or can I reveal it only when i need it? This is comes up frequently.
One of the biggest barriers to adoption that has prevented me getting adoption in wider teams is - as silly as this sounds - not directly scm functionally related but user experience on connected items for tickets.
I personally love the fact I can have issues and docs in same repo as code - it was one of the first things that attracted me to Fossil and has proven itself on my own projects repeatedly. However I loose people every time I bring up the issues page up because its not how many teams work today - they use tools with a Kanban interface that connects or is associated to their repo. I was very excited to Steve Landers initial work (http://www.eurotcl.tcl3d.org/eurotcl-2016/presentations/Euro...) in this direction - but that seems to have not progressed into Fossil core - i hope it does (or something like it) go into Fossil-NG.
Last but not least and not web interface but workflow related is CI integration. I now know Ron Perrella developed a Jenkins plugin (see https://github.com/rjperrella/jenkins-fossil-adapter ) but when this question came up - I did not have an answer and could not find anything on the home page etc.
I like using Fossil - its easy to use and has a great feature set but the above are some of the issues that I have seen that caused folks to stop looking at it and go back to other tools they use today.
--depth=1 occasionally breaks repos because of the way Git works. I THINK (don't cite!) that Git stores submodule information in the master repo's history. So when I do a depth=1 clone with something that has submodules, I literally don't receive the metadata about the submodule information. But now the local history I do have is borked, and the only way to really fix it is to rm -rf the destination and start again.
But it's typically directories with submodules that also have massive histories. Like ffmpeg, for example. Yay.
--
Git doesn't have a "just grab me this one file or directory over there" option. It would probably be possible, but would probably be a massive hack to implement without even considering the internal architecture of Git - I don't know how the packfile format works (been meaning to find out one of these days) but it does seem that it shoves multiple files into the same packfile databases.
--
Finally, I am really happy to hear that Fossil-NG is somehow (?!?) going to be able to import Git repositories. I never wanted to learn Git - I've been trucking along like the XKCD above, but somewhere along the way I realized that it just wasn't the superior architecture and was glad I'd never adopted it. At some point I hope to learn Fossil and Mercurial, with Git a begrudging afterthought.
I love how Git is referred to not once but twice as a _legacy_ client xD
If I'm understanding what you mean it's been able to do that for a long time, bidirectionally https://www.fossil-scm.org/xfer/doc/trunk/www/inout.wiki
Most often you can get away with --depth=100 or something like that, but what's really needed is a way to fetch a sha1 and not only branches and tags. This is however not as easy at it seems, since only sha1 that are accessible from any tag or branch should be allowed for fetching (otherwise we've a security hole).
I'm not sure if this is implemented in git yet, and I'm not sure if all git hosting providers support it.
That said, all the pieces are there to add a modern web UI with very little effort.
Any idea how hard to just inject some css?
As an example, switching between folders in the source tree feels faster than it does using Explorer. This is what the web should be.
I’ve toyed with the idea of making my own mostly-compatible interface but I wouldn’t want to be using a non-upstream syntax (especially if I’m the only one using it).
I know it is silly, but I cannot help myself. Sorry.
The "porcelain" is the user-visible part, the "plumbing" (hidden within the walls) is the behind-the-scenes part. Originally, the "porcelain" commands were shell scripts wrapping the "plumbing" executables (written in C).
(Possibly relevant: "[...] When asked why he called the new software, "git," British slang meaning "a rotten person," he said. "I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git." -- https://www.pcworld.idg.com.au/article/129776/after_controve...)
It seems I really do learn something new every day! :)
I'm hoping for someone to implement these with git-notes. Code review is already covered by git-appraise, but issue tracking and some kind of wiki would be nice. I know there are projects that are working on this but none that are very far.
Git's UI may not be great but I'm already used to it and it doesn't bother me.
> This allows, for example, a Fossil-NG user to clone and use a repository out of GitHub while continuing to use the superior Fossil user interface.
I totally disagree here; I don't think Fossil user interface is superior at all!
The Web UI doesn't fare better and it somewhere on the lower half of my UX shitlist.
Have to point out typing the filename is unnecessary, however. Just run "fossil open" on the repository file once and from there on out any fossil command in that directory will run against said repo.
During my testing I never encountered that command much, though it doesn't really relieve the problem of having to double-open a repository; open folder, then open repo.
When I change a directory in Git, it automatically `fossil open`'s the current repo.
If no repository file is specified there should be an automatic fallback. Or even better, make using a non-default repo file a special flag, just like in git.
I don't really want to have to deal with opening something or connecting something when changing directories should be sufficient.
Have you even used it? I'm using both fossil and git and I find fossil's CLI and integrated documentation vastly susperior to git's in terms of usability.
Honestly, there are times Subversion’s a fine option. If your repo is 24GB, you may be in one those times.
I really appreciate the mindset that Dr. H and friends have brought to both SQLite and Fossil - that is - minimal and efficient code with very low dependencies.
I first came across fossil-scm when I was looking for a simple way to host some development repos for a small group; it is so much easier with the integrated cli/server than what I found with git. Also, I love the ease of setting up replication and the he single file format.
Keep up the good work, glad to see there is some focus on the next generation!
I'd like to second the feature request mentioned elsewhere in this thread about having some for of access control on sub-trees or files within a fossil project - but - maybe that could be accomplished by simply doing a separate project / vendor tree type pattern IDK.
It works with mercurial and git. I like the fact it's very simple and straightforward:
- Issues are maildirs in `.issues`, named with hashes
- The original description and subsequent comments are messages in those maildirs
- Metadata like status, severity, etc. are headers on the description message
If you want a UI to browse issues, just point any mail reader at `.issues`.
If you want a UI to input issues or comments, just set your EDITOR or VISUAL env var to either a text editor or an email editor (I use both: Emacs with `message-mode` ;) ).
If you want a Web UI, just use any maildir renderer (I use mhonarc).
I can see the value for small and/or personal projects, but beyond that is there a good reason to not use seperate best of breed tools?
It is similar to trac, more bare bones but about as functional, and infinitely faster and more responsive. It is also completely distributed; do you have a copy of your issues and discussions for the day github eats them?
The bug tracker can be heavily customized, and get ready to do so, but it still has irritating limitations that are, when I checked a few years ago, WONTFIX limitations. Sending emails on bug tracker activity is one.
(I've seen people talk about workarounds, like writing cron jobs to monitor the RSS feed of a fossil repo and send off an email, and, frankly speaking that is not a very good solution. It's going to be a little fragile and it's not administerable by non-scripting-savvy folks.)
The wiki is also kinda wonky. Doing file attachments is weird, or was when I used it, the markup is non-standard (not mediawiki, not markdown), etc.
The worst part is, while I can learn to work around the various oddities that basically all spring from Fossil being the product of folks who don't use a lot of other tools (and consequently don't see what other tools have essentially standardized on), I can't reasonably expect my less-savvy team members to be as dedicated in learning this one tool, because, ultimately, for what?
How is fossil so much better than github or whatever? It didn't get us any farther, except now people have to learn some quirky new interface stuff. Day-to-day, zero benefit.
FWIW, it looks like the current version supports Markdown in the Wiki.
> The bug tracker can be heavily customized, and get ready to do so, but it still has irritating limitations that are, when I checked a few years ago, WONTFIX limitations. Sending emails on bug tracker activity is one.
The modern Fossil versions can be compiled with real Tcl for scripting, rather than just TH1, which makes solving this problem, and a pile of other automation-centric issues, very trivial--at least if you don't mind coding in Tcl. (NB, you only need to do this on the central server, for obvious reasons; everyone else can just use the off-the-shelf binaries.)
The rest of your comment completely stands, and is why I don't actually use Fossil.
Think of basic github functionality packed in a stand alone, self-hosting binary with a really good CLI and integrated help, ticketing, users and web interface to manage most of that, do diffs, create zip/tar archives, patches, change repo properties. It can also work in a client/server fashion, somewhat similar to subversion, but it's a distributed VCS instead so every client and server retains a full copy of the repository. The repository is replicated instead of sharded, so if you clone it you've got all the branches, all the tickets, everything but the unversioned content, the users, the settings and the css themes. Thus, your backups are equal to the number of clients in the event that you somehow manage to damage the repo on the server (which is just a repo where everyone syncs). It's also very easy to pick up without much wading through the manuals, something I always find myself doing when using git. Every command has a `fossil help <command>`. Most of the functionality is also usable through the web interface. It just works seamlessly on multiple platforms.
> Are there certain types of projects where it just works better for you than git?
Smaller projects, as in not Linux kernel sized. Projects where you don't throw a myriad of binaries in the VCS; there's the `unversioned` command for that. Projects where you have a relatively stable team, not a lot of random outside collaborators like on most succesful opensource projects on github. Projects where you'd want to self host or maybe keep private. I also use it on servers for configuration versioning.
* Single file repository with proper transactional semantics (it's an SQLite DB) rather than a "pile of files" implementation. I can trivially and safely copy the repository, send it as a mail to a new collaborator, etc.
* Fossil is a single executable. Unlike Git or Mercurial, that makes installation trivial.
* The whole system is remarkably clean, simple, and lacking in cruft. This also makes it easy to explain and get people started.
* Fossil has a well thought-out system for tags and named branches; they are persistent, but can be renamed. This is different from Git, where history tends to be largely a soup of anonymous objects, and Mercurial, where it is impossible to rename branches.
* It comes with a built-in wiki and distributed ticketing system. If you want to self-host rather than rely on GitHub/Bitbucket, that's already a very useful feature.
* `fossil undo` is very useful, even though it supports only one level of undo.
* The ability to store and share unversioned files is often very convenient.
Things I don't like about Fossil:
* The console interface is sometimes too simplistic for some commands (`fossil timeline` is one of the biggest offenders); it errs in the opposite direction from Git and relies on a GUI too much for basic operation (though I'd still prefer it over Git, but not necessarily other VCSes). That said, you can script it fairly adequately either with the JSON interface or even through direct SQL queries if you don't mind investing the time.
* The workflow for external contributions for contributors without commit access is more cumbersome than necessary; in principle, `fossil bundle` serves that need, but it lacks some features (you can't bundle non-commit artifacts, for example).
* Commit messages all get squished into a single line of output. You could argue that wiki pages or technotes are the proper way to document more complex information (so you don't have to sift through commit messages), but it's difficult to relate them to a specific commit and they aren't supported by `fossil bundle`, as mentioned above. There's some unfinished work on attaching remarks to commits [1], but this work seems dormant.
* Scalability is even more of a problem than with other distributed version control systems if you're dealing with really big repositories (not that those other systems necessarily cover themselves in glory, either), though the situation has improved in recent years.
[1] https://www.fossil-scm.org/index.html/timeline?r=remarks-on-...
You could obviously edit the underlying sqlite data store if you really wanted to, but there is no UI and they consider that a feature. While I'm sure I'm coming off as judgey I can understand their points, even if I feel like it would lead to a mess at every company I've worked at.
It is nice that additional things besides source can be tracked, bug requests for instance.
This is probably in reference to this old message by Richard D. Hipp [1]:
"Fossil, in contrast, is designed to remember everything. Fossil was specifically designed to support the DO-178B inspired development process used by SQLite, with few developers and a complete and immutable audit trail for all inputs."
DO-178B, now superseded by DO-178C [2], was an FAA standard used for the approval of commercial software-based aerospace systems.
[1] https://www.mail-archive.com/fossil-users@lists.fossil-scm.o...
However, yes, that is not the only possible workflow. SVN and CVS have been used on very large projects with moderate success. SQLite development is done in fossil. It's not impossible to do it correctly with immutable history.
That's because mutable history is not part of the normal workflow that's being encouraged by fossil. You will see that "wrong" branches are simply tagged as "mistake" in the Fossil or SQLite repositories [1]. Branches are merged rather than rebased and the web UI is built around the assumption of having branches as distinct, named entities, rather than having them coalesced into the mainline. Fossil also uses autosync by default, where commits are automatically pushed to the master repository, which further discourages changing history.
If you simply want a local checkpointing mechanism (where you snapshot revisions at intervals with the intent to later combine them into a single meaningful commit), that's what private branches or `fossil stash snapshot` are for. Commit metadata, such as commit messages, can be changed later, but the edits leave an audit trail.
A major reason here is specifically that changes are supposed to always have an audit trail.