46 ms·

Fossil vs Git

301 points by afiori 8y ago

fxfan 8y 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 8y 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.
- sigzero 8y ago
  Fossil is made by the same gentleman (D. Richard Hipp) that gave us SQLite.
  - gjvc 8y 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 8y ago
    Yes indeed, and he comments here as "SQLite".
- ethelward 8y 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 8y 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...
  - rkangel 8y 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.
- Chyzwar 8y 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.
  - fxfan 8y 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
    - palerdot 8y ago
      Interesting ... One sane thing about git is, it is very difficult to lose data. You have to work out of your way to lose data like delete your local and remote histories. Even if that is the case, if someone else has branched meanwhile, it can be restored without any fuss.
      - pseudalopex 8y ago
        Git makes it difficult to lose committed data. It's easy to lose uncommitted changes. Also, someone can know that changes are in the reflog but not how to recover them without making a bigger mess.
        mewse 8y ago
        That's a really interesting criticism to make. Can you specify a version control system which doesn't make it easy to lose uncommitted changes?
        rejschaap 8y ago
        The other half of the story is that git also makes it easy to commit.
- rndgermandude 8y 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.
  - cryptonector 8y 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 8y 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 8y 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.
  - SQLite 8y ago
    Perhaps the OP is referring to this: https://www.sqlite.org/whynotgit.html#the_mental_model_for_git_is_needlessly_complex https://www.sqlite.org/whynotgit.html#the_mental_model_for_g...
    - jtms 8y ago
      All these concepts are extremely useful in practice. I do not see them in any way as “needlessly” complex. Difficult to learn... maybe, but not just for the hell of it.
    - BeetleB 8y ago
      Other than the staging area, hg has all of these.
    - cryptonector 8y ago
      The Git index is one of its most powerful features. Try doing a `git add -e` sometime. You get to do a bunch of work in the workspace then split it up usefully at commit time.
  - pmoriarty 8y 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".
- rkangel 8y 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 8y 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 8y 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.
    - pseudalopex 8y ago
      Git was more popular for C, Perl, and Ruby. Mercurial was more popular for Java and Python. It was far ahead on Windows. Google and Atlassian bet on Mercurial well after GitHub existed. The idea that only one could win would have been strange to a lot of people at the time.
  - sys_64738 8y ago
    Linus definitely helped and he pretty much killed cvs (not the drug chain).
    - war1025 8y ago
      You mean git killed SVN right? SVN killed CVS in my understanding.
- Illniyar 8y 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.
  - pseudalopex 8y 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.
- jeltz 8y 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 8y 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-robertson 8y 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 8y 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 8y 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.
- jtms 8y 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.
- cryptonector 8y 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).
- markmark 8y ago
  "git caught on despite mercurial being much superior" mercurial wasn't superior.
echofavor 8y ago
Thanks for sharing. You can also share your ideas for free on www.echofavor.com
deepaksurti 8y ago
The Fossil Logo [1] resembles so much the Lisp Lizard! [2] [1] https://fossil-scm.org/fossil/doc/trunk/www/index.wiki https://fossil-scm.org/fossil/doc/trunk/www/index.wiki [2] http://xahlee.info/UnixResource_dir/writ/logo_lisp.html http://xahlee.info/UnixResource_dir/writ/logo_lisp.html
anilakar 8y 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.
- fxfan 8y ago
  Have you actually tried their model of bug tracking and code revision integrated?
  - Frondo 8y 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.
    - jeltz 8y ago
      I guess the ability to use the bug tracker while offline is a nice advantage, but for that to be worth it it needs to be competitive with centralized bug trackers. It is just like distributed code review tools, I wish there was any that was good enough but the ones that exist are too primitive to be worth the small gain of being able to seamlessly review code while on a flight.
    - fxfan 8y ago
      The parent I replied to had an issue with the (assumed) model. You have an issue with features. All your points are valid- the parent had no points to debate validity of.
jordigh 8y 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 8y ago
  In git you can do `git commit --amend --no-edit` to update your last commit, in case anyone is wondering.
  - GhostVII 8y 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.
- gugagore 8y 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/ http://www.davidchudzicki.com/posts/first-parent/
  - 8y ago
Vinnl 8y 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 8y 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`.
  - Vinnl 8y ago
    Thanks, that makes sense then.
- mannykannot 8y ago
  One should not have to choose - the history of complete units of work should be an abstract view of the detailed history.
  - cryptonector 8y ago
fche 8y 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.
- eesmith 8y 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 https://fossil-scm.org/fossil/doc/trunk/www/quickstart.wiki .
- raimue 8y 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 8y 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 8y ago
  Huh. I've just used another git clone of the repo, but the worktree command seems to fit my uses very well. Thanks.
  - paulddraper 8y ago
    Git clone is still a fine solution, and the one I prefer. Worktree adds the ability to share config and save disk space.
    - fiddlerwoaroof 8y ago
      The other advantages of worktree are: you can update the remotes of all the checkouts at once with git fetch and you can see all the places your repository is checked out with a git command.
booleandilemma 8y 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.
- afiori 8y 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 8y 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.
  - cryptonector 8y 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 8y 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.
aboutruby 8y ago
Always surprises me how Fossil is popular on HN but very much not outside a few projects (e.g. sqlite)
- eesmith 8y 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 8y 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.
    - bch 8y ago
      I use it for lots of projects, spanning years of work, including commercial projects with ~20 devs. Those projects aren’t public, and I’m sure lots of other people do use it that way. It’s still not going to rival the install base of git.
      - cuspycode 8y ago
        I use it too. I like to self-host my commercial projects, and when I decided to move away from Subversion about seven years ago I did consider Git, but the ease of self-hosting Fossil made the choice for me. Just plug it into apache httpd and off you go. Some time later GitLab became available, so now I'm also running a GitLab instance. But the Fossil server has much smaller footprint and is easier to manage.
bensummers 8y 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 8y ago
  For what it's worth, Git has a command for an instant web server https://git-scm.com/docs/gitweb https://git-scm.com/docs/gitweb
- Drdrdrq 8y 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 8y ago
ldap https://www.fossil-scm.org/xfer/tktview/ec667f74f8 https://www.fossil-scm.org/xfer/tktview/ec667f74f8
palerdot 8y 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.
- bch 8y 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 https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki
skywhopper 8y 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.
- cryptonector 8y 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 8y 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 https://9fans.github.io/plan9port/man/man4/fossil.html
SQLite 8y ago
Additional links for the curious: https://fossil-scm.org/fossil/doc/trunk/www/quotes.wiki https://fossil-scm.org/fossil/doc/trunk/www/quotes.wiki https://www.sqlite.org/whynotgit.html https://www.sqlite.org/whynotgit.html
- Terretta 8y 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.
deleted 8y ago
[deleted]
kurtisc 8y 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.
- SQLite 8y ago
  Here is an attempt to clarify why I think implementation does matter: https://www.sqlite.org/whynotgit.html#git_makes_it_difficult_to_find_successors_descendents_of_a_check_in 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.
  - cryptonector 8y 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 8y 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 8y 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 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/ https://www.saltycrane.com/blog/2017/05/git-worktree-notes/
- reificator 8y ago
  Relevant: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
- randallsquared 8y 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 8y ago
    Disk space?
    - tmm1 8y ago
      git clone --local will hardlink the existing git objects from the first checkout so no extra space is required.
  - _pmf_ 8y ago
    Shitty monorepos that measure hundreds of GB.
  - raimue 8y 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.
brobdingnagians 8y 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 8y 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 8y ago
svn again?
miguelmota 8y ago
That comparison table made me dislike fossil even more. Fossil took something that’s not broken, and broke it.
- rwbt 8y ago
  I disagree. I would suggest you to atleast research it more before coming to such strong conclusions.
  - miguelmota 8y 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 8y 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.
- cryptonector 8y ago
  Fossil's design and implementation are indeed admirable. Its insistence on merges is not.
randallsquared 8y 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).
- cryptonector 8y 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.
stesch 8y ago
Would you recommend using fossil for Unity3D projects? Needs to exclude certain files and being able to deal with binary files.
- jay_kyburz 8y ago
  Or Unreal. I don't really like Perforce.
- rwbt 8y 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 8y 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 8y 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?
- shawkinaw 8y 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.
  - SQLite 8y ago
    I never thought I needed bisect, until I had it. Now I can't live without it.
    - shawkinaw 8y ago
      Yeah totally fair point. I figured there’s probably some usecase I haven’t run into for this feature. Still, I think it says something that I’ve never missed it despite some fairly advanced Git usage.
- cryptonector 8y 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.
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
vkaku 8y ago
Some of those features are not features.
joshka 8y 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
cryptonector 8y ago
https://gist.github.com/nicowilliams/a6e5c9131767364ce2f4b3996549748d https://gist.github.com/nicowilliams/a6e5c9131767364ce2f4b39...
joshka 8y 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.
- pseudalopex 8y 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.
  - cryptonector 8y 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.
    - pseudalopex 8y ago
      If you mean a squashed history, I agree. At that scale I think the advantages outweigh the disadvantages.
      - cryptonector 8y ago
        Not squashed, not exactly, more like: clean and linear. Linear means: no merge commits. Clean means that a sequence of commits like this: Add feature XYZ Fix bug I just found around that code Fix typos in XYZ Fix bug in XYZ Add tests for XYZ Fix another bug I found around that code Fix bug in XYZ fixup! Add feature XYZ fixup! Fix bug I just found around that code becomes: Fix bug ... (not related to XYZ) Fix second bug ... (not related to XYZ) Add feature XYZ You would do this by doing something like `git rebase --autosquash origin/master`, then `git rebase -i origin/master` to reorder the remaining commits as above. Reword the commits to add ticket IDs to the commit subjects for all of these, if you have this as a requirement or have an issue tracker. Force push your branch, do one last round of build, test, review, and push when all looks good (else rinse, repeat). Maybe you'll realize that XYZ is two features, not one, and then you might split that up into two commits (again, using `git rebase -i`, mark that commit for "edit", `git reset HEAD^`, `git add -e`, `git commit -m 'Feature WXY'`, then `git add`, then `git rebase --continue`. Some commits got squashed, maybe some got split, and all got reordered. The resulting history is easy to read. This takes a bit more work. But once you get into this workflow, it begins to become second nature, and you get good at it and it doesn't slow you down. The benefits are well worth the learning curve, and it's not that steep.
joshka 8y 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/ https://blogs.msdn.microsoft.com/devops/tag/git/ (first article https://blogs.msdn.microsoft.com/devops/2018/06/25/supercharging-the-git-commit-graph/ https://blogs.msdn.microsoft.com/devops/2018/06/25/superchar...)
avar 8y ago
Previous discussion 9 months ago about the "Why SQLite Does Not Use Git" page at https://sqlite.org/whynotgit.html https://sqlite.org/whynotgit.html which has much of the same info: https://news.ycombinator.com/item?id=16806114 https://news.ycombinator.com/item?id=16806114
shrmn 8y ago
I agree with those who said they prefer git's "clean" commit history.
intertextuality 8y 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 8y ago
The comparison on GPL vs BSD is henious. The only disadvantage is that you lose the opportunity to be selfish.

301 points by afiori 8y 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 8y 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.
sigzero 8y ago
Fossil is made by the same gentleman (D. Richard Hipp) that gave us SQLite.
- gjvc 8y 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 8y ago
  Yes indeed, and he comments here as "SQLite".
ethelward 8y 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 8y 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...
- rkangel 8y 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.
Chyzwar 8y 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.
- fxfan 8y 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
  - palerdot 8y ago
    Interesting ... One sane thing about git is, it is very difficult to lose data. You have to work out of your way to lose data like delete your local and remote histories. Even if that is the case, if someone else has branched meanwhile, it can be restored without any fuss.
    - pseudalopex 8y ago
      Git makes it difficult to lose committed data. It's easy to lose uncommitted changes. Also, someone can know that changes are in the reflog but not how to recover them without making a bigger mess.
      - mewse 8y ago
        That's a really interesting criticism to make. Can you specify a version control system which doesn't make it easy to lose uncommitted changes?
        rejschaap 8y ago
        The other half of the story is that git also makes it easy to commit.
rndgermandude 8y 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.
- cryptonector 8y 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 8y 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 8y 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.
- SQLite 8y ago
  Perhaps the OP is referring to this: https://www.sqlite.org/whynotgit.html#the_mental_model_for_git_is_needlessly_complex https://www.sqlite.org/whynotgit.html#the_mental_model_for_g...
  - jtms 8y ago
    All these concepts are extremely useful in practice. I do not see them in any way as “needlessly” complex. Difficult to learn... maybe, but not just for the hell of it.
  - BeetleB 8y ago
    Other than the staging area, hg has all of these.
  - cryptonector 8y ago
    The Git index is one of its most powerful features. Try doing a `git add -e` sometime. You get to do a bunch of work in the workspace then split it up usefully at commit time.
- pmoriarty 8y 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".
rkangel 8y 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 8y 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 8y 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.
  - pseudalopex 8y ago
    Git was more popular for C, Perl, and Ruby. Mercurial was more popular for Java and Python. It was far ahead on Windows. Google and Atlassian bet on Mercurial well after GitHub existed. The idea that only one could win would have been strange to a lot of people at the time.
- sys_64738 8y ago
  Linus definitely helped and he pretty much killed cvs (not the drug chain).
  - war1025 8y ago
    You mean git killed SVN right? SVN killed CVS in my understanding.
Illniyar 8y 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.
- pseudalopex 8y 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.
jeltz 8y 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 8y 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-robertson 8y 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 8y 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 8y 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.
jtms 8y 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.
cryptonector 8y 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).
markmark 8y ago
"git caught on despite mercurial being much superior" mercurial wasn't superior.

echofavor 8y ago

Thanks for sharing. You can also share your ideas for free on www.echofavor.com

deepaksurti 8y ago

The Fossil Logo [1] resembles so much the Lisp Lizard! [2] [1] https://fossil-scm.org/fossil/doc/trunk/www/index.wiki https://fossil-scm.org/fossil/doc/trunk/www/index.wiki [2] http://xahlee.info/UnixResource_dir/writ/logo_lisp.html http://xahlee.info/UnixResource_dir/writ/logo_lisp.html

anilakar 8y 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.

fxfan 8y ago
Have you actually tried their model of bug tracking and code revision integrated?
- Frondo 8y 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.
  - jeltz 8y ago
    I guess the ability to use the bug tracker while offline is a nice advantage, but for that to be worth it it needs to be competitive with centralized bug trackers. It is just like distributed code review tools, I wish there was any that was good enough but the ones that exist are too primitive to be worth the small gain of being able to seamlessly review code while on a flight.
  - fxfan 8y ago
    The parent I replied to had an issue with the (assumed) model. You have an issue with features. All your points are valid- the parent had no points to debate validity of.

jordigh 8y 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 8y ago
In git you can do `git commit --amend --no-edit` to update your last commit, in case anyone is wondering.
- GhostVII 8y 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.
gugagore 8y 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/ http://www.davidchudzicki.com/posts/first-parent/
- 8y ago

Vinnl 8y 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 8y 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`.
- Vinnl 8y ago
  Thanks, that makes sense then.
mannykannot 8y ago
One should not have to choose - the history of complete units of work should be an abstract view of the detailed history.
- cryptonector 8y ago

fche 8y 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.

eesmith 8y 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 https://fossil-scm.org/fossil/doc/trunk/www/quickstart.wiki .
raimue 8y 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 8y 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 8y ago
Huh. I've just used another git clone of the repo, but the worktree command seems to fit my uses very well. Thanks.
- paulddraper 8y ago
  Git clone is still a fine solution, and the one I prefer. Worktree adds the ability to share config and save disk space.
  - fiddlerwoaroof 8y ago
    The other advantages of worktree are: you can update the remotes of all the checkouts at once with git fetch and you can see all the places your repository is checked out with a git command.

booleandilemma 8y 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.

afiori 8y 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 8y 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.
- cryptonector 8y 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 8y 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.

aboutruby 8y ago

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

eesmith 8y 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 8y 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.
  - bch 8y ago
    I use it for lots of projects, spanning years of work, including commercial projects with ~20 devs. Those projects aren’t public, and I’m sure lots of other people do use it that way. It’s still not going to rival the install base of git.
    - cuspycode 8y ago
      I use it too. I like to self-host my commercial projects, and when I decided to move away from Subversion about seven years ago I did consider Git, but the ease of self-hosting Fossil made the choice for me. Just plug it into apache httpd and off you go. Some time later GitLab became available, so now I'm also running a GitLab instance. But the Fossil server has much smaller footprint and is easier to manage.

bensummers 8y 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 8y ago
For what it's worth, Git has a command for an instant web server https://git-scm.com/docs/gitweb https://git-scm.com/docs/gitweb
Drdrdrq 8y 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 8y ago

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

palerdot 8y 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.

bch 8y 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 https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki

skywhopper 8y 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.

cryptonector 8y 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 8y 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 https://9fans.github.io/plan9port/man/man4/fossil.html

SQLite 8y ago

Additional links for the curious: https://fossil-scm.org/fossil/doc/trunk/www/quotes.wiki https://fossil-scm.org/fossil/doc/trunk/www/quotes.wiki https://www.sqlite.org/whynotgit.html https://www.sqlite.org/whynotgit.html

Terretta 8y 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.

deleted 8y ago

[deleted]

kurtisc 8y 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.

SQLite 8y ago
Here is an attempt to clarify why I think implementation does matter: https://www.sqlite.org/whynotgit.html#git_makes_it_difficult_to_find_successors_descendents_of_a_check_in 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.
- cryptonector 8y 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 8y 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 8y 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 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/ https://www.saltycrane.com/blog/2017/05/git-worktree-notes/

reificator 8y ago
Relevant: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
randallsquared 8y 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 8y ago
  Disk space?
  - tmm1 8y ago
    git clone --local will hardlink the existing git objects from the first checkout so no extra space is required.
- _pmf_ 8y ago
  Shitty monorepos that measure hundreds of GB.
- raimue 8y 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.

brobdingnagians 8y 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 8y 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 8y ago

svn again?

miguelmota 8y ago

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

rwbt 8y ago
I disagree. I would suggest you to atleast research it more before coming to such strong conclusions.
- miguelmota 8y 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 8y 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.

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

randallsquared 8y 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).

cryptonector 8y 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.

stesch 8y ago

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

jay_kyburz 8y ago
Or Unreal. I don't really like Perforce.
rwbt 8y 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 8y 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 8y 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?

shawkinaw 8y 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.
- SQLite 8y ago
  I never thought I needed bisect, until I had it. Now I can't live without it.
  - shawkinaw 8y ago
    Yeah totally fair point. I figured there’s probably some usecase I haven’t run into for this feature. Still, I think it says something that I’ve never missed it despite some fairly advanced Git usage.
cryptonector 8y 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.

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

vkaku 8y ago

Some of those features are not features.

joshka 8y 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

cryptonector 8y ago

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

joshka 8y 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.

pseudalopex 8y 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.
- cryptonector 8y 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.
  - pseudalopex 8y ago
    If you mean a squashed history, I agree. At that scale I think the advantages outweigh the disadvantages.
    - cryptonector 8y ago
      Not squashed, not exactly, more like: clean and linear. Linear means: no merge commits. Clean means that a sequence of commits like this: Add feature XYZ Fix bug I just found around that code Fix typos in XYZ Fix bug in XYZ Add tests for XYZ Fix another bug I found around that code Fix bug in XYZ fixup! Add feature XYZ fixup! Fix bug I just found around that code becomes: Fix bug ... (not related to XYZ) Fix second bug ... (not related to XYZ) Add feature XYZ You would do this by doing something like `git rebase --autosquash origin/master`, then `git rebase -i origin/master` to reorder the remaining commits as above. Reword the commits to add ticket IDs to the commit subjects for all of these, if you have this as a requirement or have an issue tracker. Force push your branch, do one last round of build, test, review, and push when all looks good (else rinse, repeat). Maybe you'll realize that XYZ is two features, not one, and then you might split that up into two commits (again, using `git rebase -i`, mark that commit for "edit", `git reset HEAD^`, `git add -e`, `git commit -m 'Feature WXY'`, then `git add`, then `git rebase --continue`. Some commits got squashed, maybe some got split, and all got reordered. The resulting history is easy to read. This takes a bit more work. But once you get into this workflow, it begins to become second nature, and you get good at it and it doesn't slow you down. The benefits are well worth the learning curve, and it's not that steep.

joshka 8y 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/ https://blogs.msdn.microsoft.com/devops/tag/git/ (first article https://blogs.msdn.microsoft.com/devops/2018/06/25/supercharging-the-git-commit-graph/ https://blogs.msdn.microsoft.com/devops/2018/06/25/superchar...)

avar 8y ago

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

shrmn 8y ago

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

intertextuality 8y 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 8y ago

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