Fossil vs Git

https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki

by afiori • 7 years ago

301 247 7 years ago

fxfan5• 7 years ago

I'm surprised git caught on despite mercurial being much superior (hadn't heard of fossil before). Git has the following shortcomings which are major (some shared by other VCS too)

1) UI- terrible, terrible UI

2) Unncessarily complex data model

3) Doesn't scale well to large repos (until Microsoft's VFS- windows only)

(and many others...)

rco8786• 7 years ago

Unncessarily complex data model

The git data model is certainly complex, but I'd be curious to hear why you think it's 'unnecessarily' so. I often try and drum up a new SCM in my head and the data model gets pretty complex every time.

sigzero5• 7 years ago

Fossil is made by the same gentleman (D. Richard Hipp) that gave us SQLite.

gjvc• 7 years ago

    $ fossil init wibble
    project-id: c8d025508afd55c31cebedfe244a3b62f39fb6eb
    server-id:  8b340295f8268f742f91c5e972195efc0c6e578f
    admin-user: gjvc (initial password is "c5d7ba")

    $ file wibble 
    wibble: SQLite 3.x database (Fossil repository), last written using SQLite version 3026000

jpeeler• 7 years ago

Yes indeed, and he comments here as "SQLite".

ethelward• 7 years ago

To give a personal, subjective point of view of why I switched from hg to git:

  - hg was horribly slow compared to git;
  - I love the branchs model used in git to let several persons work on different parts of the same project, and I could never find a satisfactory equivalent using hg idiomatisms.

It is true that hg has a far better UI in general, but Magit fixes this problem for me.

sirn• 7 years ago

To add more praises about Magit: I would really love to use other DVCS, especially Fossil because it has built-in issue tracker and Wiki and all, but to be unable to use Magit with Fossil is a bigger drawback for me to make a switch.

At this point, I can basically do most of Git commands in Magit with just muscle memory; say, stage everything in the tree, commit amend, reset author and dates, then force push (I know) to remote I would just press with evil-magit: <SPC>gsSc-Racp-fpy (<SPC>gs for invoking Magit, S to stage everything, c to enter commit mode, -R set the reset author flag, a amend commit, p enter push mode, -f set the force flag, p push to origin, y confirm force push)

It may sounds complicated, but the Magit UI is discoverable, and once you're used to it you can do anything without even looking at the UI...

rkangel2• 7 years ago

The UI thing is more than superficial though. Yes, the command line is horribly inconsistent (and that can be fixed with Magit), but the real issue is that if you want to do anything non-trivial you have to understand how git works - what the object model is, how refs work etc.

I used mercurial successfully, quite heavily, and I couldn't tell you much about how it's implemented.

Chyzwar2• 7 years ago

1) It is not beginners friendly but for day to day dev you only need to understand few commands.

2) Data model brings speed that was not possible before. git won VCS space because of sheer performance.

3) Scale just fine. Just windows have a really bad filesystem and Windows codebase is the pathologic case.

fxfan5• 7 years ago

I am not a beginner and not trying to boast but pretty smart and experienced.

The problem is that the edge cases that come up have solutions which need to be looked up- not derived from understanding. And when you're scared of data loss, its a very frustrating situation

ethomson2• 7 years ago

It has nothing to do with the Windows filesystem; Git simply cannot support a 5 GB working tree on any filesystem. You can call this "pathological" but this throws a lot of shade on monorepos without much critical examination of how or when they might be useful.

rndgermandude• 7 years ago

I dread every time I have to use hg (and when I can use the git bindings for it). And I was using hg before I was using git.

git has a terrible UI, granted, but I find the hg UI pretty terrible too. I really hate their approach to branching (tho that is remedied these days with e.g. bookmarks to some extent).

Speaking of data model, I find gits model to be a lot saner. I REALLY hate that hg spams my disk with tons and tons of files within the .hg directory. Ever cloned e.g. the mozilla hg repos? ugh. Bonus points for their fancy name escaping mechanism in those files, which had me run into "path too long" issues on windows boxes a couple of times already.

cryptonector22• 7 years ago

Mercurial's bookmarks tend to get into a bad state for me. With Git it's trivial to fix things. With Mercurial I just can't figure anything out, and I think that's because Mercurial tries so hard to hide how things work and to tell me how I should do my work.

setquk• 7 years ago

4) lots of foot guns

I would rather like a new option which was designed as a VCS from day one, that is user friendly and fast. Fossil is actually nearly there (I used it for a bit for some private projects)

donatj• 7 years ago

2) Unncessarily complex data model

Hmm? It’s just a directed graph of SHA1s under the hood. Seems pretty simple to me once you understand that. My understanding was that Hg’s data model is actually way more complicated with more pointers.

As everyone else is chiming in, the reason git won was speed. I haven’t used mercurial in a few years but at the time when I was looking to replace SVN, git did everything seconds faster than Hg which made it the clear winner.

SQLite6• 7 years ago

Perhaps the OP is referring to this: https://www.sqlite.org/whynotgit.html#the_mental_model_for_g...

pmoriarty3• 7 years ago

"the reason git won was speed"

It wasn't just speed, it was also that the Linux kernel was developed under git, that Linus created git, and the existence of github, which a lot of people liked.

After a while, it also just developed a critical mass where the attitude of people/companies that weren't using it almost inevitably became one of "everybody else is using git, so we should too".

rkangel2• 7 years ago

Git won over Mercurial simply due to Github. There were some other minor contributing factors - association with Linus, speed - but they are insignificant compared to how popular Gihub was (for good reason) and therefore how many people were exposed to git.

The Mercurial alternatives like bitbucket just didn't have the same spread, and we got stuck with year after year of teaching new people a difficult interface.

kasey_junk• 7 years ago

It’s even more specialized than that git one because github made public repos free & private repos paid. Bitbucket did the reverse.

If not for that difference we’d all think of git as that bizarre source control Linus makes the Linux devs use.

georgyo• 7 years ago

Git won the war before GitHub existed. More projects were switching to git than hg.

GitHub was then mirroring open source projects git repos without asking. (Which I think is fine, but ruffled some feathers back then)

GitHub could have easily been hghub, but they targeted git because it was already winning.

sys_64738• 7 years ago

Linus definitely helped and he pretty much killed cvs (not the drug chain).

Illniyar• 7 years ago

It is rare that adaption has anything to do with the strength of the technology involved. Usually the winners are those that are early to market, are adapted early by industry leaders and/or have better marketing.

In this case the reason is most definitely the fact that it used in Linux, easily one of the biggest open source projects ever. I would wager a guess that if Mercurial was created earlier, Git would probably never have been created, let alone be adapted for Linux.

pseudalopex7• 7 years ago

Mercurial and Git started around the same time. Linus was concerned that Mercurial was similar enough to BitKeeper that BitMover might threaten anyone who worked on it or at least anyone who had used BitKeeper.

jeltz2• 7 years ago

The simple data model is the best part of git so I have no idea what you are referring to. I do not see how one could make it any simpler and still use it to implement a DVCS. The main reasons I picked Git over Mercurial were the data model and the performance.

kyrra• 7 years ago

Re 2: HG doesn't have a published data model. I believe they have created 2 or 3 models at this point so far, but I happens under the hood. They can do this as there is only 1 implementation of HG, so no need to worry about compatible as much.

dan-robertson2• 7 years ago

I think git and hg are both pretty bad in different ways.

Both have pretty terrible UI but so long as one uses magit, git comes out way on top.

The data models are different and suffer different problems. A main issue with git is that it is stupid about file copies and renames. An issue with hg is that it doesn’t work well with long running forked histories (i.e. like git branches) because it stores the set of revisions of a file as a list of blocks of “complete file” or “diff from previous version in this list”

Both have scaling problems to large repos and algorithm/data structure problems which cause too many operations to be e.g. O(size of history) at least. I suppose this is better than Darcs’ model of “commit on Friday and hopefully it will be done by Monday.” If hg we’re naturally good at scaling than e.g. Facebook wouldn’t be putting so much effort into trying to make it scale (e.g. using inotify instead of looking throughout the tree for changes (which I think shouldn’t count as any vcs gains from this), having a mergeless history, rewriting a ton of hg in rust (git was always partly in C and there is now also libgit2)).

The thing that makes me most sad about hg is the lack of a really good (ie good and emacs-based) ui.

I’m all for different vc systems being developed and I think it would be good to see some real innovation potentially break up the current git-hg hegemony.

I think there are lots of good things about fossil (e.g. using an actual database that is going to scale well and avoid data corruption instead of using a specialised data structure that is hard to change and likely not so corruption resistant or battle tested or scalable but maybe let’s your data structure be “faster” for certain operations)

Another interesting vc system being developed at the moment is pijul which can be simply described as “like darcs but fast and more likely to be correct”. It feels a bit like it’s fitting in with the current trend of CRDTs, although it’s core data structure is not a CRDT as that would imply that all merges have some deterministic resolution (ie merge conflicts do not happen) and that is not the case, instead files are allowed to be merged into a first-class conflicted state which can then be resolved by later patches.

u801e• 7 years ago

A main issue with git is that it is stupid about file copies and renames.

Could you elaborate on this? As far as I know, file copies and renames will still use the same blob, but the tree referencing the blob can reference it using a different path in the case of a rename or reference it more than once in the case of a copy.

zaarn• 7 years ago

Git has the advantage of being the right kind of terrible.

If you only push commits to a branch and use GUI tools like Github or Gitea for merging, chances are you're never going to be exposed to anything more complicated than 'add; commit; push'.

Even merging isn't that terrible and while still being painful, git makes it somewhat clear what you want.

The problem is; if you want people to use something else, you need to improve over git in the areas that matter to most people (ie, 'add; commit; push').

Git is terrible but just good enough that improvement over that terrible will be hard to accept for the mainstream.

jtms2• 7 years ago

Unnecessarily complex data model

I have been using git since it was released and have never needed to think about its underlying data model in order to accomplish dev tasks. Also I suspect that any complexity in the data model was quite necessary to implement its api and features in a performant way.

cryptonector22• 7 years ago

I'm not sure any VCS scales well to huge repos, and the MSFT work in this space is truly amazing. I love, for example, their use of a Bloom filter to make git blame fast!

I actually like the git UI. Like many git power users, I've come to terms with a subset of the UI that I know how to use very well. The thinness of Git's abstractions lets me think of complex VCS operations as I do when reading or writing code. If the cognitive load is too high, you can always just use a merge-heavy workflow and stop thinking about the mechanics, but I recommend instead to understand the mechanics.

The data model in Git is hardly more complex than Fossil's or Mercurial's, and it's copy-on-write all the way, which makes it very safe (think ZFS).

markmark2• 7 years ago

"git caught on despite mercurial being much superior"

mercurial wasn't superior.

deepaksurti• 7 years ago

The Fossil Logo [1] resembles so much the Lisp Lizard! [2]

[1] https://fossil-scm.org/fossil/doc/trunk/www/index.wiki

[2] http://xahlee.info/UnixResource_dir/writ/logo_lisp.html

anilakar• 7 years ago

Funny how they say that Git uses a "Bazaar-style development" process when Bazaar literally is another VCS.

I'm also not convinced it's a good idea to merge your bug tracker and version control.

fxfan5• 7 years ago

Have you actually tried their model of bug tracking and code revision integrated?

Frondo• 7 years ago

I have, and the built-in tools are weak or cumbersome to the point of being useless (or were when I moved off to bitbucket).

The wiki had its own weird markup at the time, so people who might have helped me write documentation were faced with learning a weird new markup (they were volunteers, that's a tough ask.)

The bug tracker had no way to send emails, and you were expected to rig up some external systems to do that. Maybe it's changed now?

Just lots of little usability things too.

These issues had such ardent defenders on the mailing lists, too, I became convinced the situation would likely never improve.

Aside from the cute idea of having your version control in one self-contained file with a single-binary server, I can't think of anything fossil does better than any other system.

YMMV.

jepler• 7 years ago

There's a famous comparison of development styles that in turn predates the Bazaar software by years if not a decade.

solomatov• 7 years ago

Here's the wikipedia article about this work: https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

stavros• 7 years ago

They don't mean bzr the VCS, they mean Cathedral/Bazaar.

jordigh6• 7 years ago

I'm a big, huge fan of recording what should have happened instead of recording every typo and forgotten semicolon in your history. There's a difference between draft commits and published commits. When I'm reading published commits, i.e. history, I just want to know your intent, not your typos. So what are the tools that Fossil offers to make sure I don't have to see your typos in the history?

byte1918• 7 years ago

In git you can do `git commit --amend --no-edit` to update your last commit, in case anyone is wondering.

GhostVII• 7 years ago

I don't think it updates your last commit, it just deletes it and creates a new one with the same changes (along with any new changes being amended). It's an important distinction because if you push to a remote branch that has the old commit, you need to overwrite it with the new one. Commits themselves are immutable.

gugagore2• 7 years ago

I'm also a big fan of not deleting data. I don't like squashing commits, for example. But I also want to be able to see high-level intent.

If instead of "squashing", it were "grouping", I'd be happy. I could encapsulate a bunch of messy commits that I made while I didn't know what I was trying to do. The intent would be clear at a higher level, but if you want to dig in to see what it actually took me to achieve that, you can see all my experimentation by looking at the commits inside the group.

Groups should be able to be nested, of course.

The only way I know how to achieve this in git is my relying on no-fast-forward merges. There's a post detailing this approach [1], but unfortunately a lot of git tools don't support this workflow that well. I haven't gotten it to work well in gitlab, for example.

[1] Git First-Parent-- Have your messy history and eat it too : http://www.davidchudzicki.com/posts/first-parent/

SSLy• 7 years ago

If instead of "squashing", it were "grouping", I'd be happy. I could encapsulate a bunch of messy commits that I made while I didn't know what I was trying to do. The intent would be clear at a higher level, but if you want to dig in to see what it actually took me to achieve that, you can see all my experimentation by looking at the commits inside the group.

That oddly sounds like a feature available in mercurial.

marktangotango2• 7 years ago

How often dou you actually look at this historic detail you seek to maintain? Daily, weekly, monthly? Is it more for to satisfy a feeling than an actual need? I mean if some junior dev wallows on some branch for 40 commits, I don’t want to see any of that, I just want to see what was finally merged.

nobody2712• 7 years ago

I tend to commit, read my commit, and then find all kinds of mistakes and have to amend or redo the changes on a separate branch. If those options aren't available I just have a messed up commit history. This is all because git makes modifying your commit history very difficult to do. I think this immutable feature makes git worse because I have no intention of lying to myself or my team about my commit history. I would just like easier tools for pruning and organizing it. Instead my commit history is always a mess that better represents my knowledge of git than the progress of whatever I'm working on.

bluejekyll• 7 years ago

I sometimes go back and “group” commits with a ‘git rebase -i’ and squash commits that are related.

Is that similar to what you’re talking about?

jordigh6• 7 years ago

You misunderstand me. Almost everyone does. I do not think you should squash all of your changes into a giant hairball commit, and I don't think first parent (which is effectively the same thing) solves this problem either.

I think each of your commits should be individually rewritten until each commit makes sense and tells a single, indivudal story that makes sense on its own, while at the same time be completely atomic and as small as possible.

You created a new function? That's one commit. Take a moment to explain why this function is going to be useful in future commits.

You called that new function from several new spots? That's another commit. Explain why each of these calling sites requires this function.

You decided that there had to be some style and whitespace changes? That's another commit. This one can go without explanation.

You found an old bug along the way that can be fixed with a one-line change? That's another commit. Hey, nice catch. Perhaps a few lines about this bug and why your small change fixes it?

Together, these are all individual scenes of a larger story. But the larger story doesn't need the behind-the-scenes of how you came up with these scenes. I don't need to see all your drafts of each scene. I just want the final scenes that make up the final story.

cryptonector22• 7 years ago

I don't care about how many typos you made while developing a thing. I only care about your upstream's history not getting re-written, but I don't care to see your dev history -- it's a distraction at best.

FPGAhacker• 7 years ago

I don’t squash commits very often, but I do re-order them. When i have a pile of changes to commit that aren’t always perfectly related, I will sometimes check in the cart before the horse. Rebase lets me correct that order.

So perhaps fossil really “shows what actually happened” but perhaps the more accurate statement is it shows the actual commit order. And that may not reflect the actual order of what was done, leading to an inversion of the logical progression of the code.

That said, I’m going to try it anyway for the ticket system and wiki. I use a two tier vcs system. “Official” work goes into svn and I have no control over that. Interim work for me is in git. But I’d like tickets and wiki docs to help me track issues that I can’t get to right away and sometimes forget about after a month or two.

cryptonector22• 7 years ago

I want clean, linear history in my upstreams. Always. You can leave pointers to your work branch(es), and even use a second parent commit in commits for this, but no actual merging, always rebasing, and always preserving clean, well-broken-up commit history.

StreamBright• 7 years ago

I cant even remember the last time I was looking at a commit in git or any other source control system. I usually look at pull requests and what has changed.

Example files changed view in Github:

https://github.com/TechEmpower/FrameworkBenchmarks/pull/4311...

Vinnl2• 7 years ago

Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors, dead-ends, experimental branches, and so forth.

I think this is an interesting distinction. The question is: what is the function of the history? Is it to document what happened - and if so, shouldn't every keystroke be committed? Or is it to document which changes relate together, and e.g. should be reverted together? Or perhaps something else entirely?

One thing that isn't mentioned is whether Fossil supports working offline as well as Git does. My impression from this page is that it emphasising creating every branch on a server as well, which implies you need to be connected? If so, I'd consider that a "missing feature" as well, as it's something I use regularly enough and that's important enough that it'd be something I'd miss if it weren't there.

messe• 7 years ago

One thing that isn't mentioned is whether Fossil supports working offline as well as Git does. My impression from this page is that it emphasising creating every branch on a server as well, which implies you need to be connected? If so, I'd consider that a "missing feature" as well, as it's something I use regularly enough and that's important enough that it'd be something I'd miss if it weren't there.

The way fossil works is that by default autosync is turned on, which means that if you are connected to the internet all of your commits, wiki and issue tracker changes are synced to the server.

In the case that you're not connected, everything still works as expected, and will sync back up next time you're online and try to commit or just run `fossil update`.

Vinnl2• 7 years ago

Thanks, that makes sense then.

mannykannot3• 7 years ago

One should not have to choose - the history of complete units of work should be an abstract view of the detailed history.

cryptonector22• 7 years ago

So the abstract view should be useful and free from noise, but you want to be able to get at the noise anyways. But to what end? What's it to you if I typo and make other silly errors during development? What if I never commit until I'm done?

If I never commit until I'm done you will not see my mistakes, but if there's nothing like `git add -e`, then I won't be able to split up my commits logically and so the upstream history when I push will be devoid of useful detail. Even if I do commit early and often, I will almost never do all my work in the order and logical splits that makes most sense for others to see after I'm done... unless you give me a powerful rebase facility.

No rebase -> no clean history upstream, only lots and lots of merges with pointers to messy history (where authors commit early and often) or shallow history (where they commit only when done) in branches you'll almost never want to see. This is the worst possible outcome! The only logical history organization here is "the large merge commit". You get far too little abstraction on the actual history and far too much noise if you want more detail.

There's also the risk that, because you cannot separate bits of work as "done" and push them separately, your branch will accumulate ever more change and reach a point where you cannot continue without doing much more work, and then you won't be able to easily salvage any of the work done to that point in that branch. This one is a big deal to me too.

fche• 7 years ago

The comparison lacks a big item: distributed-ness: the whole git-remote push & pull symmetry. It allows not only offline bare-minimum operation, but full offline development, then later online merging. I don't see any signs that fossil can do the same.

The comparison re. licenses is factually mistaken in several ways, but that's probably not worth a great deal of discussion - it's too religious a topic.

eesmith4• 7 years ago

Most comparisons points out the major differences, rather than all the ways they are the same.

As you can see from bullet point #5 from the fossil home page, it works offline:

CGI/SCGI Enabled - No server is required, but if you want to set one up, Fossil supports four easy server configurations.

and #6 concerns later online merging:

Autosync - Fossil supports "autosync" mode which helps to keep projects moving forward by reducing the amount of needless forking and merging often associated with distributed projects.

There's also the quick start guide with an overview of distributed-ness - https://fossil-scm.org/fossil/doc/trunk/www/quickstart.wiki .

raimue3• 7 years ago

In fact, due to the integration, Fossil supports offline work not only for code, but also for changes in the wiki and the issue tracker. You can do full offline development on code, update documentation in the wiki, comment on issues and change their state and merge all these changes later when you are back online.

tux1968• 7 years ago

One of the bullet point advantages listed for Fossil of allowing multiple checkouts per repository is also supported by Git. There has always been a way to do it, but since Git 2.5 or so, the "worktree" sub command was added for this purpose.

emerongi• 7 years ago

Huh. I've just used another git clone of the repo, but the worktree command seems to fit my uses very well. Thanks.

paulddraper2• 7 years ago

Git clone is still a fine solution, and the one I prefer.

Worktree adds the ability to share config and save disk space.

booleandilemma• 7 years ago

Your commit history should read like a published novel, not a first draft.

I think I might’ve read something like that in the Pro Git book and it rings true with me.

The philosophy of Fossil is to preserve the full history, which I think is a mistake.

afiori3• 7 years ago

A nice feature would be the ability to group and split commits afterwards; like adding a "novel branch". So that you could keep both the exact history and a parallel high level description.

grive• 7 years ago

Your high-level description resemble a cover letter used on some open-source project to introduce a patch series, justifying the changes.

You could achieve the same by using an empty commit, or tracking those in the bug tracker.

DCVSs are already complex enough, this just seems like scope creep, trying to emulate a feature that is actually part of another tool (the bug tracker or the mailing list, depending on the structure).

Another issue is that it would foster a mentality where people would simply don't care about the exact history and push really badly structured commits, relying on the second-level history to explain their work. Except that if someone publishes something, it's not for this person, it's to be read by other people. The dev could keep a local branch with all their commits if they are so inclined, but that should never be sent to a shared server.

Most people are already bad enough at writing proper commits and dividing their work, I think your feature would make it worse.

cryptonector22• 7 years ago

Not after the fact. It's too late then, and it won't get done. History has to be pretty when you push it. The idea of being able to group commits is very nice, and IIUC BitKeeper had that.

GuB-42• 7 years ago

Both approaches have value. And you'll find books advocating both ways.

Fossil takes a stance, git doesn't. It makes fossil less versatile but it is not a mistake. They never claimed Fossil to be the perfect solution for every project.

aboutruby2• 7 years ago

Always surprises me how Fossil is popular on HN but very much not outside a few projects (e.g. sqlite)

eesmith4• 7 years ago

How do you estimate Fossil's general popularity?

Most projects are invisible to you, like in-house projects that never see the light of day. If Fossil is used by 1% of those projects, that's still a lot of projects.

How can you tell if Fossil is popular in HN? By my reading, only two people in this thread use it. More than that mention having never heard of it before, or make statements where it's clear they don't really understand what it is.

dymk• 7 years ago

Fossil is posted to and discussed on HN all the time. It's a novelty, it differs in design from the popular tools that people actually use in their day-to-day jobs.

There's really no reason to think that Fossil is used internally at a rate higher than its public-facing usage. And I've literally never seen a project that uses Fossil aside from Fossil examples.

sigzero5• 7 years ago

Yeah, it's probably not "widely" used. I know the Tcl dev team uses it for Tcl and Tk. That's pretty much the only one I know.

There is a online hosting service: http://chiselapp.com

A list of public projects (I was kind of surprised there were so many): http://chiselapp.com/repositories/

rkeene23• 7 years ago

I run ChiselApp.com if there are any questions about it. I inherited it from James Turner, the creator of it.

SQLite6• 7 years ago

Some data:

The fossil-scm.org server gets between 1500 and 2000 distinct human visitors per day on weekdays. (Lower traffic on weekends. Robots are excluded from the count. "distinct" means visitors having different IP addresses.) This is perhaps orders of magnitude less than git-scm.org (I'm guessing - anybody have stats?) but it is also non-trivial. With ~1750 visitors per day somebody must be using it. And I would guess that most actual users do not visit the site daily. (When was the last time you visited git-scm.org?)

FWIW, today has already seen in excess of 10,000 distinct human IPs, likely due to this HN post.

aboutruby2• 7 years ago

When was the last time you visited git-scm.org?

Like most people, I go to Google which then redirects me to the correct Stack Overflow question/answer the most often. I think git-scm.org is mostly a guide to get started and the reference documentation.

bensummers• 7 years ago

I choose fossil at a time when it wasn't clear which one of fossil, Mercurial, or git would "win".

I choose it because it had a very clear and easy UI, guided you towards a way of working that is suitable for small teams (ie 99.99% of all projects), and had an approach to history which made it unlikely you'd ever accidentally lose work.

The only thing which has ever made me sad about my choice is pressure from people who think everyone should use git.

It also has some very nice features, like being able to give you a full web UI just by running it as a CGI process on a web server.

It is worth trying (and it can import and export git history). Just remember it's not git.

judge2020• 7 years ago

For what it's worth, Git has a command for an instant web server https://git-scm.com/docs/gitweb

Drdrdrq• 7 years ago

Been there, but with Mercurial. We chose it because it has sane CLI interface (as opposed to git), but eventually had to switch because we wanted to use GitLab. Not much difference all in all, except with git I still need to search the net to find a proper command, while with hg I could usually guess it and just checked help for confirmation. It saddens me that git won... Awful UX. But they had GitHub and now GitLab.

based2• 7 years ago

ldap https://www.fossil-scm.org/xfer/tktview/ec667f74f8

palerdot2• 7 years ago

Push or pull a single branch
The fossil push, fossil pull, and fossil sync commands do not provide the capability to push or pull individual branches. Pushing and pulling in Fossil is all or nothing. This is in keeping with Fossil's emphasis on maintaining a complete record and on sharing everything between all developers.

This is a kind of deal breaker if it just pushes all of my private WIP branches to remote. Is there any genuine use case for this kind of functionality? Apart from that, this looks interesting.

bch3• 7 years ago

Fossil does have private branches[0] and the recommended way to publish private work is to integrate it into a non-private branch and sync as usual.

[0] https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki

skywhopper• 7 years ago

Ugh. Certainly there are things that git could do better but reading this makes me want to run far away from Fossil and never look back.

You can argue about whether “the Unix philosophy” is best for specific tools like version control, and maybe you can argue that “the Unix philosophy” isn’t really about simple vs complex tools. But I don’t think I’ve ever heard nor would I think you could find evidence that the Unix philosophy is “it just works”. That claim makes me pretty certain that this is a tool I want to avoid at all costs. And the tone of the rest of this article confirms it.

cryptonector22• 7 years ago

My feeling as well. It's sad because Fossil underneath the covers is a lot like Git, but with a SQL RDBMS as the store. Fossil's design is much more powerful than Git's for that reason alone. But that super-opinionated attitude they have is a disaster. Run away.

butterisgood• 7 years ago

fossil is also the name of a file system server on Plan 9 that dealt with hashes on the venti archival storage server.

https://9fans.github.io/plan9port/man/man4/fossil.html

SQLite6• 7 years ago

Additional links for the curious:

https://fossil-scm.org/fossil/doc/trunk/www/quotes.wiki

https://www.sqlite.org/whynotgit.html

Terretta• 7 years ago

I’ll pull what I consider an important quote into this thread:

”SQLite uses cathedral-style development. 95% of the code in SQLite comes from just three programmers, 64% from just the lead developer. And all SQLite developers know each other well and interact daily. Fossil is designed for this development model.”

FWIW, I consider this an extraordinarily productive development model.

Agile may be about People and Interactions over Processes and Tools, but (and it’s too often forgotten) all dev must first be about effective output in the problem space. So, how do you optimize ratio of Outcomes to People/Interactions/Processes/Tools? This model.

FWIW, I also consider Linus’ and Guido’s “BDFL” approach a way the bazaar is channeled back into a cathedral.

kurtisc• 7 years ago

git-worktree seems to give git the multiple-checkouts feature.

Also, this page seems to do the common but frustrating thing of advertising how something is implemented as a feature. I'm sure it's very interesting to the developers that it uses a database in the backend or that your side-project is written in a niche language but, as an end user, I just don't care.

SQLite6• 7 years ago

Here is an attempt to clarify why I think implementation does matter: https://www.sqlite.org/whynotgit.html#git_makes_it_difficult...

When the design of a system makes something difficult, people tend to avoid doing that thing. The Git data design makes extracting some kinds of historical information difficult, with the result that many common tools (ex: GitHub) don't bother. This reduces the information available to users, resulting in reduced situational awareness.

I make no claim that Fossil is perfect in this regard. My only claim is that Fossil is better.

Whether you use Fossil or not, I don't much care. But I really would like you to understand some of the features of Fossil that (I think) make it better than Git, and perhaps start adding some of those features to your favorite VCS, be it Git or something else. Understand the general concepts, then port those concepts to other systems.

cryptonector22• 7 years ago

Fossil is better. Because it has a better design. Because it uses SQL (which makes it possible to write queries on the fly in ways that cannot be done in other VCSes). The use of SQL, and Fossil's use of fairly generic SQL, allowing the use of RDBMSes other than SQLite3, is brilliant, and would make it trivial to make Fossil scale better than MSFT is making Git scale, though with the caveat that you'd probably still end up wanting things like a Bloom filter for speeding up file-level log/blame, but you could probably make Bloom filters a transparent, RDBMS-level query optimization.

Fossil is worse. Because it doesn't have a CoW design in the format of its DB, though it does have a CoW design in its SQL schema. However, because SQLite3 is so good at handling power failures and such, this has not been a big deal (and indeed, Git has had more problems there owing to its ad-hoc storage model). This, of course, could be fixed by adopting a CoW backend for Fossil. This problem is hardly fatal.

Fossil is worse. Because of its insistence on merge workflows and not implementing rebase.

Fossil is worse. Because it has minimal mindshare. Mindshare is absolutely critical. The lack of rebase support is part of the reason that Fossil cannot get the kind of mindshare that would allow it to replace Git. And it may well be too late, but you never know.

It turns out that rebase is the more critical thing for me and many others. I think the Fossil community doesn't know it and doesn't get it because the projects it deals with don't have thousands of developers active every day. And, of course, rebase is really just a feature that can be built by using scripting on top of a cherry-pick primitive (which Fossil does have), so there's no real excuse for not having it.

Incidentally, GitHub used to also insist on merges in its browser UI, but eventually they added the "rebase and merge" feature.

Mercurial too resisted rebase. Boy did they. And they gave in and implemented it. Ironically many people rebased in Mercurial long before the feature was adopted -- we did, in Solaris engineering, a dozen years ago.

My prediction is that Fossil too will eventually support rebase (out of the box) for the same sorts of reasons that all other VCSes have tended to get it.

If I had to use Fossil, the first thing I'd do is script a rebase around cherry-picking. Because I could, because the market demands this feature, because it's a built-in feature of competing, more-successful VCSes, Fossil ought to adopt it. You wouldn't have to use it. You might have a way to turn it off on a project-by-project basis. But the rest of us should get to use it on our projects.

All in all, I neither use nor recommend Fossil. But I am envious, and I would use it, if it had rebase.

nharc• 7 years ago

As someone currently working in a project where parts are managed with git and others with fossil, I have a strong preference towards git. One major issue with fossil is the non-existent ecosystem. It simply does not integrate well with other frameworks and tools (e.g. Yocto/OE). Migrating to git entirely would be much better for the team and workflow as a whole, but unfortunately the seniors who are using fossil are quite hostile towards git, for mostly political reasons. The irony is that they have big performance issues with fossil, precisely due to the fact that fossil records everything and the push/pull commands sync the entire repo, not just one branch.

Fossil also lacks an equivalent to git submodules, which should be added to the list of features found in git, but not in fossil.

jlebar• 7 years ago

Git: One check-out per repository

Fossil: Many check-outs per repository

git allows multiple checkouts per repo.

Official docs (good luck): https://git-scm.com/docs/git-worktree

Random person's blog that explains it more clearly: https://www.saltycrane.com/blog/2017/05/git-worktree-notes/

reificator• 7 years ago

Relevant: https://git-man-page-generator.lokaltog.net/

randallsquared2• 7 years ago

I have no idea what use case is satisfied by git worktree, based on that blog post. In the case that you desperately needed to have two branches checked out, why not just clone twice?

cheerlessbog• 7 years ago

Disk space?

_pmf_• 7 years ago

Shitty monorepos that measure hundreds of GB.

raimue3• 7 years ago

With multiple clones, you would need to remember to update each clone regulary not only from remote, but also push/pull locally in case you want to compare your state with other branches.

A 'git checkout' on a large repository such as the Linux kernel may take a while (bound by I/O performance). Regulary switching between branches with many changed files becomes annoyingly slow.

If you keep multiple clones, you actually keep multiple copies of the full history, which seems like a waste of disk space (yes, deduplicating filesystems exist, but are rarely used).

git worktrees are also very useful if you have unfinished on a release branch. You do not have to make temporary commits or stashes you forget about, you can just leave the modified files as they are and switch to a different worktree to continue your work on another branch.

microcolonel• 7 years ago

why not just clone twice?

Sometimes this is fine, but if the history is large enough (like in the case of the Linux kernel), it can start to get out of hand space-wise. If you have a deduplicating filesystem, that can help, but only so much.

Of course, there is a way to use clone which hardlinks the objects.

teeray• 7 years ago

I use it to build multiple versions of Go from source locally. When a new release branch appears, I just `git worktree add release-branch-1.12 ../go1.12`, then `cd ../go1.12/src` and `GOROOT_BOOTSTRAP=../go1.11 ./make.bash`. It makes it very easy to try out betas while staying in sync with patch releases. It’s also great for keeping an old version of Go around if you have some project that requires it.

kzrdude• 7 years ago

Shared set of local branches, they might be many

LukeShu2• 7 years ago

A workflow in a few projects I work with:

Have a "develop" branch that does not contain any generated files, and a "master" branch that does. Have a post-commit hook that uses a worktree pull every commit from "develop" to "master" and generate any files.

That type of workflow is possible by cloning the local repo, but is kludgey and brittle enough prior to worktrees, I had never considered that workflow viable.

Joky2• 7 years ago

The main reason I'm using worktree instead of two clones is that you can commit in one and cherry-pick in the other immediately, without pushing/fetching. You can rebase the branch in development in worktree 2 on top of something else in worktree 1.

wincent• 7 years ago

I usually use it to keep an unrelated branch easily accessible. For example:

- website generator (JS stuff) on "master" branch checked out at $PROJECT_ROOT, and website content (Markdown files) on "content" branch checked out using git-worktree at $PROJECT_ROOT/content.

- Project source code on "master" branch checked out at $PROJECT_ROOT, and images needed for GitHub README file in "media" branch checked out using git-worktree at $PROJECT_ROOT/media.

I never use it for quickly switching topics (that's the git-stash use case, it you can just make a temporary commit).

brobdingnagians• 7 years ago

I think it really comes down to preference. Both work well and for different reasons and styles. Including tech notes and docs into the VCS could be nice, if you use it, but like most project management, it comes down to how you work-- that's one reason why there isn't a one-size-fits-all project management product that is infintely better than any other offering. There are plenty of times I wished I had something like the embedded tech notes to explain design decisions. I use git myself currently, but I've wanted to dip my toes into fossil for awhile to see if it matched my workflow. I think storing the whole repo in an SQLite database was brilliant-- self contained and you don't have a problem slicing the data to get things like all parent commits or descendant commits.

achiang• 7 years ago

The comparison table in section 2 could just as easily live in the git docs, under a page called "why use git instead of fossil".

fishdaemon• 7 years ago

svn again?

miguelmota2• 7 years ago

That comparison table made me dislike fossil even more. Fossil took something that’s not broken, and broke it.

rwbt2• 7 years ago

I disagree. I would suggest you to atleast research it more before coming to such strong conclusions.

miguelmota2• 7 years ago

You're right; did more research and it makes more sense considering the problem niche it's solving. I jumped to assumptions too soon.

blacksqr• 7 years ago

In my experience, feature sets tend to converge within product categories, but I'm happiest in the long term with the program whose original design decisions I'm most sympathetic with.

In fossil's case this was architectural simplicity, an easy-to-use basic set of commands with a discoverable set of expanded commands that always seemed to meet my needs as they cropped up, collaboration features in the pre-GitHub era were killer. There are a few discrete layers of hackability for customization with minimal risk of blowing your project away.

Fossil still meets my needs admirably, and I stick with it even though it's harder to make the case for it in the current era of feature convergence.

cryptonector22• 7 years ago

Fossil's design and implementation are indeed admirable. Its insistence on merges is not.

randallsquared2• 7 years ago

From the features in Fossil and not in git:

Branches in Fossil have persistent names that are propagated to collaborators via push and pull. All developers see the same name on the same branch. Git, in contrast, uses only local branch names, so developers working on the same project can (and frequently do) use a different name for the same branch.

Since the default is to use the name from upstream when checking out a branch, the vast majority of the time devs working in git also use the same name for a branch. Given that, this seems better stated as a feature for git (Easily Renamed Branches, perhaps).

cryptonector22• 7 years ago

That is very silly of the Fossil community. On the surface Fossil branching is a lot like Mercurial branching, but under the covers it's just like Git's branching: branches are just bookmarks for commits. And Git very much has local tracking branches (that track upstream branches), so it's as Fossil-like as you want, but doesn't pretend to enforce a merge-only workflow.

That's really the bottom line when it comes to Git vs. all the others: Git doesn't enforce a merge-only workflow, not even as a default, while all the others generally do.

Mercurial, for example, resisted adding cherry-pick and rebase for the longest time (just like Fossil), and when they finally added it they had to do it in gratuitously different ways from Git (e.g., you can rebase, or rewrite history, but not both at once) because they are so damned opinionated about how we all should do do our work. So now Mercurial has rebase, and it has "bookmarks" (i.e., Git-style light-weight branching), but you still can't really use it without heavy-weight branching, and you can still get into trouble where you end up with multiple tips on a branch, and it still tries to hide the machinery underneath, which makes it difficult to reason about.

Fossil also tries to hide the machinery underneath it, and that's its big sin. Just like Mercurial. The irony is that under the covers Fossil is a lot like Git but with a fabulous SQL store.

I believe the Fossil maintainers simply do not understand rebase. Or why it's necessary when you have thousands of people working on a codebase.

At Sun we did rebasing long long before that term existed, way back in the 90s (well before I went to work for them), and we did it using ancient tech known as Teamware. That's where Larry McVoy got some of his ideas, and thence Linus Torvalds. Later, when we selected Mercurial, we ended up doing rebase in Mercurial long before Mercurial adopted the feature -- we still didn't call it that, and it was all scripted. Indeed, you can rebase on Fossil just fine, if you're willing to script it around Fossil's primitive cherry-pick (which, incidentally, is pretty much how rebase is implemented in Git, though nowadays it's not scripted).

My theory is that Git -or any VCS- is only difficult to understand if you insist on abstractions that hide its mechanics completely. Abstractions are absolutely critical to what we do, so this might seem a bit incongruous, but I'm not asking for no abstractions here, just that their being leaky is actually a very useful thing in the context of VCS.

joshka5• 7 years ago

s/Renamed/Aliased/

I also would rephrase this as a missing feature from Fossil rather than a feature that is missing from git.

stesch• 7 years ago

Would you recommend using fossil for Unity3D projects? Needs to exclude certain files and being able to deal with binary files.

jay_kyburz• 7 years ago

Or Unreal. I don't really like Perforce.

rwbt2• 7 years ago

Just giving my experience - I working in rendering graphics and use fossil for version control. Some of my repos are more than 100GiB in size and fossil has no problem with it. Fossil handles binary files adequately but the only catch is file size is limited to SQLite 'Blob' size limits (which is currently 2GiB). So if you have asset files larger than 2GiB, you'll have to split it into multiple files.

zzo38computer• 7 years ago

I use Fossil for my own projects; I find it is less confusing than Git. However, I use cathedral style for my own projects, so that helps; I manage all of the code by myself but nevertheless will allow anyone to look at the code, make their own version with their own modifications (a fork of the project) (and do whatever they want with their own copy of the code), make bug reports, and submit patches for me to review, but not to directly write to the code repository (only I do that).

orev• 7 years ago

As someone not versed in either, how much does not being able to track changes forward through the history matter? It sounds like that might be pretty important, but git’s popularity would seem to indicate that it doesn’t really matter in practice?

shawkinaw2• 7 years ago

I have to say, I’ve used Git for many years now and I’ve never, ever, ever wished for this, nor even knew it wasn’t possible. So this seems like a silly thing to claim as an advantage for Fossil.

SQLite6• 7 years ago

I never thought I needed bisect, until I had it. Now I can't live without it.

cryptonector22• 7 years ago

I don't know what you mean.

In general upstreams in Git do not allow history rewriting. It's only the forks (local branches) that allow history rewriting. This is just fine.

Also, when upstreams do accept non-fast-forward pushes, there's `git rebase --onto` for recovery by downstreams.

vkaku• 7 years ago

Some of those features are not features.

joshka5• 7 years ago

The fossil all command

In git, this is pretty much a oneliner script dropped in your path and named `git-all`.

Something like (typing from memory on my non-work computer):

    #!/bin/bash
    find . -type d -depth 1 -exec git -C {} "$@" \;

Which allows any of the following to just work (I usually alias these commands):

    git all status
    git all status --short --branch
    git all pull --rebase

cryptonector22• 7 years ago

https://gist.github.com/nicowilliams/a6e5c9131767364ce2f4b39...

joshka5• 7 years ago

Git puts a lot of emphasis on maintaining a "clean" check-in history.

This seems like an inaccurate phrasing of this. Git (the tool) doesn't specifically emphasize this, but it does support this as a possible approach without excluding the other approach. Many teams have settled on development approaches with git that do indeed emphasize this, but not every team does. If you want to show your work, you sure can, but unlike fossil, git does not force this upon developers. Like the article, I don't see either approach as right or wrong, but know that I prefer the clean history approach rather than every typo commit ever.

pseudalopex7• 7 years ago

Git's linear presentation of history encourages rebasing or squashing. Mercurial keeps the branch structure, which has the advantages of both squashed and unsqusahed commits.

joshka5• 7 years ago

I use the following fairly regularly (aliased):

    git log --graph --oneline

I can understand how you could see this as an advantage, but I see forcing this on the developer as more of a disadvantage. I literally never want to see in any history commits with junk attempts to fix something. After the fact, these are the least interesting things to me.

cryptonector22• 7 years ago

Merge commits stop being interesting when you have thousands of people working on a codebase and you have tens or hundreds of thousands of branches. At that point clean, linear history is much, much simpler to understand.

cryptonector22• 7 years ago

See, if you get a choice, at least you got the choice. When you get no choice in the matter, then the tool is opinionated, and forces its developers' choices on you. Sometimes that's nice, but mostly that's when you can live with those choices. Clean, linear history is absolutely the best choice for any sufficiently large project, and never the wrong choice for small projects, so being forced to do merge workflows is really suboptimal.

joshka5• 7 years ago

The ability to show descendents of a check-in.

This is interesting. I wonder if the same thing could be achieved fairly simply in git though by keeping an extra area in the .git folder that handles reversing / denormalizing the DAG for some of the things that these reports show.

Microsoft are innovating in this area (bringing the improvements that they have in VSTS to the client). There's a good series of blog posts on this at https://blogs.msdn.microsoft.com/devops/tag/git/ (first article https://blogs.msdn.microsoft.com/devops/2018/06/25/superchar...)

avar• 7 years ago

Previous discussion 9 months ago about the "Why SQLite Does Not Use Git" page at https://sqlite.org/whynotgit.html which has much of the same info: https://news.ycombinator.com/item?id=16806114

shrmn• 7 years ago

I agree with those who said they prefer git's "clean" commit history.

intertextuality• 7 years ago

SQLite uses cathedral-style development. 95% of the code in SQLite comes from just three programmers, 64% from just the lead developer. And all SQLite developers know each other well and interact daily. Fossil is designed for this development model.

Is this not terrifying? I've always thought the distributed nature of git is part of why it's so incredible. Not relying on a few handful of individuals.

profalseidol• 7 years ago

The comparison on GPL vs BSD is henious. The only disadvantage is that you lose the opportunity to be selfish.

Fossil vs Git

Related Stories