
Fossil – Next Generation - Fice
https://www.fossil-scm.org/index.html/wiki?name=Fossil-NG
======
interfixus
I am a cranky old contrarian. I do not like huge monopolies or monoliths.
Github in itself is fine, but it rubs me the wrong way how huge and all-
pervading it has become - a sort of Facebook for coders.

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.

~~~
hota_mazi
Look, our lives (not just software lives, our entire lives) are dominated by
crappy de facto standards. They are everywhere. They imposed themselves
through inertia, laziness and by virtue of being just a tad more useful than
anything else at a time where everything else was terrible. Cable companies,
Internet providers, social networks, foods, they surround us.

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.

~~~
renox
I think that git is quite good, but I don't like the notion of 'squashing
commits': when you squash commits you loose history! I would prefer to have a
"fold/folder" of commits which could be manipulated as 'one commit' but would
instead be a set of commit and you could look inside the folder if you need
the full history.

~~~
hota_mazi
Like everything, "squashing commits" has good use cases and bad use cases.
They have all been documented to death but just as a quick reminder:

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.

~~~
Fice
In Fossil the good use case is supported by using private branches: when you
merge a private branch into a public branch, only the merge commit is pushed,
the private branch remains private.

------
krylon
I like Fossil very much. It is compact, yet offers a nice variety of features.
I especially like the integrated web interface and the fact that the Wiki,
with its entire editing history is transmitted along the regular file
operations on the repo whenever a repo is cloned or pulled. (I use Fossil to
track the source tree of scripts, little programs and SQL queries I write at
work, and of my personal "monorepo" at home where all of my toy projects live.
I.e. I have not done anything _big_ with fossil, but for smaller repos it has
served me very, very well.)

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.

~~~
loxs
Try reposurgeon

------
ketralnis
I love fossil but I have so few opportunities to use it. Almost every project
is on Github with a minority on bitbucket or gitlab and sharing code outside
of those gardens (or even between them) always feels like an uphill battle.
I've had to answer the "why not just use github?" question a lot of times. I
think that there is actually value to be had in a sort of common town square
of code in that it encourages a lot of good sharing, and I think Github has
done a great job at doing that. But the downside of the monoculture is that it
can leave the technology stagnant. Most people that I know that use git just
know five or six incantations to do the most common things and carrying that
knowledge for another VCS just seems like more overhead to them.

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

~~~
boris
>I've had to answer the "why not just use github?" question a lot of times.

We have a FAQ entry for that:

[https://build2.org/faq.xhtml#github](https://build2.org/faq.xhtml#github)

~~~
hota_mazi
> Mostly because we want complete control of our infrastructure.

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'?

~~~
comex
At the moment the post I’m replying to is in the grey, perhaps because it
comes off as aggressive.

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

------
developuh
Before I started using mercurial and git I tried fossil for a few days. It was
really good. I think the only reason my company decided to go with mercurial
and git was the lack of a service like bitbucket or github for fossil.

I am really excited to see the new avatar of fossil.

~~~
dognotdog
That's the beauty of fossil... you hardly need one! Most aspects (wiki,
issues) those services offer can be in the local repo, always accessible.

~~~
jimktrains2
I use GitHub to have a publicly accessible, discoverable, and searchable
presence for the repo.

Perhaps we should build something like gnu social (or diaspora, but not as
bad) for code projects, or build on existing distributed social networks.

~~~
zaarn
This is somewhat in the works.

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.

~~~
sytse
Issue for reference [https://gitlab.com/gitlab-org/gitlab-
ce/issues/4013](https://gitlab.com/gitlab-org/gitlab-ce/issues/4013)

------
OhSoHumble
I know it's kind of superfluous, but I could never really get into Fossil
because it had a poor UI compared to commercial offerings for Git - e.g,
GitHub, Bitbucket, and GitLab.

~~~
petre
Kind of hard and rather useless to pack most of Github's functionaliy in an
1Mb standalone binary.

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.

~~~
xwattt
> web UI is adequate

[https://www.fossil-scm.org/index.html/timeline?y=ci](https://www.fossil-
scm.org/index.html/timeline?y=ci) Adequate for what? That is just a mess of
unimportant info.

~~~
SQLite
> [https://www.fossil-scm.org/index.html/timeline?y=ci](https://www.fossil-
> scm.org/index.html/timeline?y=ci) ... 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.

~~~
petre
I use both fossil and github.

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.

------
SQLite
Author of the referenced wiki post, and of SQLite and Fossil here...

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.

~~~
dochtman
I (with my background on the Mercurial crew back in the day) definitely think
Git is ripe for disruption -- I've done some thinking on things you could do.

(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!).

~~~
dilap
Very interesting list.

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.

------
exikyut
This is absolutely awesome. I barely use Git myself - my use cases have pretty
much been [https://xkcd.com/1597/](https://xkcd.com/1597/) \- but the two main
features I _have_ needed to use are --depth=1 (to download just recent files)
and "just fetch this one file from this one directory".

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

~~~
iveqy
When using --depth=1 with submodules, git tries to clone a submodule. Let's
say its master branch to the depth of 1. However the super project does not
point to a branch but to a sha1, so except when the master branch points to
sha1, it will fail.

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.

~~~
Dylan16807
You need intimate knowledge of a commit to know its sha1, so how would that be
a security hole?

------
spdegabrielle
Amazing engineering. The UI is 1999 - but that shouldn’t distract you from the
engineering inside.

That said, all the pieces are there to add a modern web UI with very little
effort.

~~~
yjftsjthsd-h
> 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?

~~~
gecko
It’s extremely easy; there’s an entire concept of themes, and it’s trivial to
switch amongst them. Somewhere I’ve got a GitHub-circa-2012 theme for it just
to mess with people.

~~~
oso2k
I’d be interested in seeing that.

~~~
petre
[http://fossil.include-once.org/fossil-skins/index](http://fossil.include-
once.org/fossil-skins/index)

~~~
gecko
Hah, yep, that looks exactly like it. I forgot how horrid it looked.

------
ComputerGuru
I think what the world really needs is just a better cli/porcelain for git
starting with better and clearly defined terminology built around how people
actually use git and not how libgit represents its data.

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

~~~
krylon
The use of the word "porcelain" for the user-facing parts of git always makes
me cringe or giggle, because the first association that comes to my mind is a
toilet (as opposed to tableware). And just to be clear, my opinion of Git is
nowhere near that low. I do not like it very much, but I do not despise it,
either.

I know it is silly, but I cannot help myself. Sorry.

~~~
cesarb
It's not silly, it's the correct analogy. "We divide Git into high level
("porcelain") commands and low level ("plumbing") commands." ([https://git-
scm.com/docs/git#_git_commands](https://git-scm.com/docs/git#_git_commands))

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...](https://www.pcworld.idg.com.au/article/129776/after_controversy_torvalds_begins_work_git_/))

~~~
krylon
Thank you!

It seems I really _do_ learn something new every day! :)

------
maxpert
From article:

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

~~~
jaccarmac
Are you talking about the command line porcelain? If so that's certainly true,
but Fossil really shines when you use its web UI as part of your VCS use
cycle. And there's certainly room for additional porcelain as the repository
format is a well-documented SQLite file.

~~~
zaarn
Personally, I don't like either. I've found the CLI to be rather confusing,
especially since there is no default SQLite filename so I can just go without
having to type it all the time (that was last time I tried it).

The Web UI doesn't fare better and it somewhere on the lower half of my UX
shitlist.

~~~
jaccarmac
Fair enough on most points.

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.

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

~~~
jaccarmac
It's inconvenient for sure, but to be clear opening a repository is a one-time
operation. It puts a file called ".fslckout" in the current directory which
acts like the ".git" directory does for Git.

------
benmccann
I would love if SCMs made it easier to have access controls. E.g. I want to
give a contractor access to a single file or directory. That's basically
impossible with git

------
dilap
How's Fossil do with large binaries? We've got a 24GB git repo and it's...not
the greatest. (Not terrible, either, but not great.)

~~~
gecko
In the same order of magnitude as Git. The only DVCS I’ve seen handle this
well is Mercurial, and then only when you’re using all the Facebook plugins
(like remotefilelog) that effectively re-centralize it. (This is also the same
conceptual direction Microsoft’s going with their Git VFS; I just don’t think
they’re as far along yet.)

Honestly, there are times Subversion’s a fine option. If your repo is 24GB,
you may be in one those times.

~~~
dilap
The pain of git at 24GB isn't too bad -- still better off than using svn, I'd
say.

------
aquamo
I use fossil for small projects and I often import trees from GitHub into
fossil-scm to visualize and reason about the history.

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.

------
xelxebar
The idea of hosting issues along with the repo seems intriguing. Does anyone
have experience doing the same with git? Seems like some people are doing it:

[https://github.com/duplys/git-issues](https://github.com/duplys/git-issues)

~~~
chriswarbo
I use Artemis in my personal projects:
[http://www.mrzv.org/software/artemis](http://www.mrzv.org/software/artemis)

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
    

There are simple commands to list, show, add and close issues. That's it.

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

------
grogenaut
can someone explain succinctly what they like about fossil over git? I found a
few overall articles but a nice HN comment would also help if anyone is game.
Are there certain types of projects where it just works better for you than
git?

~~~
gecko
On top of the command-line user interface being much easier for most people
(it’s not _as_ orthogonal as Mercurial, but it’s much more consistent than
Git’s), the ability to have bug tracking, code, and wiki in a single
executable, where all assets (not just code) synchronize, makes kickstarting a
new project with full hosting environment ridiculously simple.

~~~
flukus
How good are the bug tracker and wiki? My immediate reaction to this idea is
to throw up in my mouth a little bit because I remember the TFS experience,
everything was integrated but all the individual components were worst-in-
class.

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?

~~~
Frondo
From the experience of someone who used Fossil for small and large projects
(solo and in teams) for 3-4 years, they aren't very good.

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.

~~~
gecko
I think your critique of the usability of the tools is completely spot-on, but
I wanted to note one thing you reminded me about here:

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

------
andrecl
Is rebasing possible in fossil? I was led to believe it was difficult since
the commit history was immutable.

~~~
jimktrains2
Last time I had this discussion I was told it's fundamentally against the
concept of fossil and that editing history is an antifeature. Also, they claim
this provides assistance in meeting regulatory standards, but never saw much
more than assertions on that.

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.

~~~
oblio
svn was used successfully for many years at many companies without having the
git "feature" of deleting history. svn obliterate was never implemented and if
people needed something like that they would use admin hacks. It was
definitely as easy as git makes it.

~~~
jimktrains2
It also comes from how git is used. With git small commits are possible. It's
nice to be able to manage those and build larger, coherent ones. Also, because
of the distributed nature, sometimes rewriting is useful to fix mistakes.

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.

------
xellisx
I was hoping this was about the old FOSSIL driver.

