20 ms·

Fossil – Next Generation

208 points by Fice 9y ago

OhSoHumble 9y ago
I know it's kind of superfluous, but I could never really get into Fossil because it had a poor UI compared to commercial offerings for Git - e.g, GitHub, Bitbucket, and GitLab.
- petre 9y ago
  Kind of hard and rather useless to pack most of Github's functionaliy in an 1Mb standalone binary. The web UI is adequate and works really well. Git does not come with a web UI of its own and the CLI is quite arcane compared to fossil. We've been happily using fossil for at least three or four years. It gets the job done without getting in the way. I'd really like to use fossil-ng on git and hg repos. That way I don't have to touch git ever again.
  - xwattt 9y ago
    > web UI is adequate https://www.fossil-scm.org/index.html/timeline?y=ci https://www.fossil-scm.org/index.html/timeline?y=ci Adequate for what? That is just a mess of unimportant info.
    - SQLite 9y ago
      > https://www.fossil-scm.org/index.html/timeline?y=ci https://www.fossil-scm.org/index.html/timeline?y=ci ... That is just a mess of unimportant info. That screen contains all and only the information I want to see. (No surprise, since I wrote that screen.) I would very much like to read more details from Xwattt about what he (or she) finds messy, unimportant, and inadequate about the timeline view of Fossil and to perhaps see examples of better presentations of development history. I wonder if Xwattt has tried clicking on two of the check-in circles in the graph from the link above, in order to get a diff between the two selected check-ins? Is that information not useful? What of the filtering options in the sub-menu? Is clicking on "Files" to see all the individual files changes in each check-in not helpful? Is clicking on a branch-name tag to see a timeline of just that one branch not something that other people ever want to do? Seriously - I'm not trolling here. I honestly what to grok what it is that Xwattt finds inadequate about the Fossil web interface, as understanding this will help to make the interface better.
      - Frondo 9y ago
        Do you use Github or Bitbucket regularly? That would be the best way to understand what people are used to, and consequently what they will expect to see (or not see). If the reply is, "fossil is meant to be different," then of course you have your answer; it shows you what you care about, not what people who are accustomed to other systems care about.
      - petre 9y ago
        I use both fossil and github. I find fossil's history graph more useful than github's commits view which is basically just a git log and only lists one branch at once. In fossil I can see all checkins on all branches simultaneously. If I want to see a signle branch I click on it. If I want to see a diff, I click on the checkin link.
      - xwattt 9y ago
        > contains all and only the information I want to see http://noisydecentgraphics.typepad.com/design/images/2008/03/11/yourproduct.jpg http://noisydecentgraphics.typepad.com/design/images/2008/03... > examples of better presentations Here it is - http://github.com/ http://github.com/ > Is that information not useful? Sure, all information useful, but presentation and usability of fossil ui is near zero. It looks like a programmer without any aesthetic taste just throw all information in random places on screen just to fill it. While UX designers polishes every checkbox, padding and font size. For example - why unreadable commit ids occupy so much space on the screen? When I open timeline - I want to read commit descriptions first, and only after that I may be interested in some commit id. I'm opening github timeline and I'm focused on commit descriptions, but fossil timeline accents me on useless commit ids! > I'm not trolling here Me too. I bet 99% of Github success is a good UX - but it is very difficult for programmer to understand it.
      - ptrott2017 9y ago
        As a long time user of Fossil who periodically tries to persuade others to use it, the challenges I have seen getting others to adopt fossil that echo XWattts comments include: Look and feel. I have tried different UI themes - github and stackoverflowesque (so-skin.txt) are the most successful in getting buys in - but out of the box fossil, tends not to get a great initial response and it is suprising how many people just stop there. Fossil timeline graph is different from Github commit view - which is the main tool many of devs I work have only used. I much much prefer Fossil graph view to Github commits I find it a lot more helpful, but others do not see it this way. This can usually be quickly solves with some on boarding training, but it is a small initial barrier friction point to adoption. Tickets and timeline - Actual user feedback said while trying to get a colleague to use Fossil -" In tickets and timeline - Whats this weird jumble of letters i have to click on - why can I not click on the ticket title?" While obliviously all tickets need a unique identifier - do i need to look at it all the time, or can I reveal it only when i need it? This is comes up frequently. One of the biggest barriers to adoption that has prevented me getting adoption in wider teams is - as silly as this sounds - not directly scm functionally related but user experience on connected items for tickets. I personally love the fact I can have issues and docs in same repo as code - it was one of the first things that attracted me to Fossil and has proven itself on my own projects repeatedly. However I loose people every time I bring up the issues page up because its not how many teams work today - they use tools with a Kanban interface that connects or is associated to their repo. I was very excited to Steve Landers initial work (http://www.eurotcl.tcl3d.org/eurotcl-2016/presentations/EuroTcl2016-Landers-KanbanTcl.pdf http://www.eurotcl.tcl3d.org/eurotcl-2016/presentations/Euro...) in this direction - but that seems to have not progressed into Fossil core - i hope it does (or something like it) go into Fossil-NG. Last but not least and not web interface but workflow related is CI integration. I now know Ron Perrella developed a Jenkins plugin (see https://github.com/rjperrella/jenkins-fossil-adapter https://github.com/rjperrella/jenkins-fossil-adapter ) but when this question came up - I did not have an answer and could not find anything on the home page etc. I like using Fossil - its easy to use and has a great feature set but the above are some of the issues that I have seen that caused folks to stop looking at it and go back to other tools they use today.
exikyut 9y ago
This is absolutely awesome. I barely use Git myself - my use cases have pretty much been https://xkcd.com/1597/ https://xkcd.com/1597/ - but the two main features I have needed to use are --depth=1 (to download just recent files) and "just fetch this one file from this one directory". --depth=1 occasionally breaks repos because of the way Git works. I THINK (don't cite!) that Git stores submodule information in the master repo's history. So when I do a depth=1 clone with something that has submodules, I literally don't receive the metadata about the submodule information. But now the local history I do have is borked, and the only way to really fix it is to rm -rf the destination and start again. But it's typically directories with submodules that also have massive histories. Like ffmpeg, for example. Yay. -- Git doesn't have a "just grab me this one file or directory over there" option. It would probably be possible, but would probably be a massive hack to implement without even considering the internal architecture of Git - I don't know how the packfile format works (been meaning to find out one of these days) but it does seem that it shoves multiple files into the same packfile databases. -- Finally, I am really happy to hear that Fossil-NG is somehow (?!?) going to be able to import Git repositories. I never wanted to learn Git - I've been trucking along like the XKCD above, but somewhere along the way I realized that it just wasn't the superior architecture and was glad I'd never adopted it. At some point I hope to learn Fossil and Mercurial, with Git a begrudging afterthought. I love how Git is referred to not once but twice as a _legacy_ client xD
- sigjuice 9y ago
  I have not tried it, but the one-liner to fetch a single file that is mentioned here https://stackoverflow.com/a/14610427/78720 https://stackoverflow.com/a/14610427/78720 seems plausible
- ketralnis 9y ago
  > Finally, I am really happy to hear that Fossil-NG is somehow (?!?) going to be able to import Git repositories If I'm understanding what you mean it's been able to do that for a long time, bidirectionally https://www.fossil-scm.org/xfer/doc/trunk/www/inout.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/inout.wiki
- iveqy 9y ago
xellisx 9y ago
I was hoping this was about the old FOSSIL driver.
ketralnis 9y ago
I love fossil but I have so few opportunities to use it. Almost every project is on Github with a minority on bitbucket or gitlab and sharing code outside of those gardens (or even between them) always feels like an uphill battle. I've had to answer the "why not just use github?" question a lot of times. I think that there is actually value to be had in a sort of common town square of code in that it encourages a lot of good sharing, and I think Github has done a great job at doing that. But the downside of the monoculture is that it can leave the technology stagnant. Most people that I know that use git just know five or six incantations to do the most common things and carrying that knowledge for another VCS just seems like more overhead to them. In a lot of ways fossil is pretty stable and hasn't seen sweeping changes in a while. It hasn't really needed them, but I'm glad that it's getting some renewed interest
- boris 9y ago
  >I've had to answer the "why not just use github?" question a lot of times. We have a FAQ entry for that: https://build2.org/faq.xhtml#github https://build2.org/faq.xhtml#github
  - bch 9y ago
    This is excellent. Addressing cargo cult development with its own self. GitHub == git, git == awesome because Linux and Linus, Linux development communications == email (turntable scratch noise)
  - hota_mazi 9y ago
    > Mostly because we want complete control of our infrastructure. That's certainly a good reason to stay away from github but a terrible reason to roll your own infrastructure. How about using a hosted gitlab instance? It's been progressing extremely quickly and even has features that github doesn't have yet. You get the best of both worlds: git and being your own master. > I am much more efficient using my mail client (mutt) and text editor (emacs) than a web browser form. That's a surprisingly myopic view point. Of course, you are entitled to your preferences but if you take your project seriously, you need to realize that the choice of an arcane bug tracking system means that most users will simply never file bugs for your project, let alone fix them and then update your bug tracking system. You are most likely facing a huge opportunity cost here and you might never have realized it, even if you might be tempted to answer that you have received bugs against your project. Think again: how many users were about to and then just gave up when they saw you use non standard tools? This is really a simple choice: whose life are you trying to make easier, yours or your users'?
ComputerGuru 9y ago
I think what the world really needs is just a better cli/porcelain for git starting with better and clearly defined terminology built around how people actually use git and not how libgit represents its data. I’ve toyed with the idea of making my own mostly-compatible interface but I wouldn’t want to be using a non-upstream syntax (especially if I’m the only one using it).
- giancarlostoro 9y ago
  I've found Source Tree to be fine to use. It's a GUI but it uses actual git names so trying commands isn't as scary. Other clients make up names and sometimes hide a lot of the magic to a scary dangerous level also harder for someone to tell me what to do and me to follow what they mean vs just doing it on Source Tree. Just wish it ran on Linux.
- krylon 9y ago
  The use of the word "porcelain" for the user-facing parts of git always makes me cringe or giggle, because the first association that comes to my mind is a toilet (as opposed to tableware). And just to be clear, my opinion of Git is nowhere near that low. I do not like it very much, but I do not despise it, either. I know it is silly, but I cannot help myself. Sorry.
  - cesarb 9y ago
    It's not silly, it's the correct analogy. "We divide Git into high level ("porcelain") commands and low level ("plumbing") commands." (https://git-scm.com/docs/git#_git_commands https://git-scm.com/docs/git#_git_commands) The "porcelain" is the user-visible part, the "plumbing" (hidden within the walls) is the behind-the-scenes part. Originally, the "porcelain" commands were shell scripts wrapping the "plumbing" executables (written in C). (Possibly relevant: "[...] When asked why he called the new software, "git," British slang meaning "a rotten person," he said. "I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git." -- https://www.pcworld.idg.com.au/article/129776/after_controversy_torvalds_begins_work_git_/ https://www.pcworld.idg.com.au/article/129776/after_controve...)
spdegabrielle 9y ago
Amazing engineering. The UI is 1999 - but that shouldn’t distract you from the engineering inside. That said, all the pieces are there to add a modern web UI with very little effort.
- yjftsjthsd-h 9y ago
  > That said, all the pieces are there to add a modern web UI with very little effort. Any idea how hard to just inject some css?
  - gecko 9y ago
    It’s extremely easy; there’s an entire concept of themes, and it’s trivial to switch amongst them. Somewhere I’ve got a GitHub-circa-2012 theme for it just to mess with people.
    - oso2k 9y ago
      I’d be interested in seeing that.
      - petre 9y ago
        http://fossil.include-once.org/fossil-skins/index http://fossil.include-once.org/fossil-skins/index
        xwattt 9y ago
        Please, never share this link again! My eyes...
        gecko 9y ago
        Hah, yep, that looks exactly like it. I forgot how horrid it looked.
- udba 9y ago
  The UI being 1999 is a positive. The website has nothing it doesn't need. There's a Dieter Rams quote on this topic. As an example, switching between folders in the source tree feels faster than it does using Explorer. This is what the web should be.
developuh 9y ago
Before I started using mercurial and git I tried fossil for a few days. It was really good. I think the only reason my company decided to go with mercurial and git was the lack of a service like bitbucket or github for fossil. I am really excited to see the new avatar of fossil.
- petre 9y ago
  There is Chisel but it's just a hosting service for Fossil. You don't get any kind of added value other than not having to host it yourself.
- dognotdog 9y ago
  That's the beauty of fossil... you hardly need one! Most aspects (wiki, issues) those services offer can be in the local repo, always accessible.
  - jimktrains2 9y ago
    I use GitHub to have a publicly accessible, discoverable, and searchable presence for the repo. Perhaps we should build something like gnu social (or diaspora, but not as bad) for code projects, or build on existing distributed social networks.
    - zaarn 9y ago
      This is somewhat in the works. There is an issue on GitLab to enable federated pull requests and I believe Gogs/Gitea community is working on getting some sort of standard figured out if I'm not mistaken.
      - sytse 9y ago
        Issue for reference https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 https://gitlab.com/gitlab-org/gitlab-ce/issues/4013
  - hinkley 9y ago
maxpert 9y ago
From article: > This allows, for example, a Fossil-NG user to clone and use a repository out of GitHub while continuing to use the superior Fossil user interface. I totally disagree here; I don't think Fossil user interface is superior at all!
- jaccarmac 9y ago
  Are you talking about the command line porcelain? If so that's certainly true, but Fossil really shines when you use its web UI as part of your VCS use cycle. And there's certainly room for additional porcelain as the repository format is a well-documented SQLite file.
  - zaarn 9y ago
    Personally, I don't like either. I've found the CLI to be rather confusing, especially since there is no default SQLite filename so I can just go without having to type it all the time (that was last time I tried it). The Web UI doesn't fare better and it somewhere on the lower half of my UX shitlist.
    - jaccarmac 9y ago
      Fair enough on most points. Have to point out typing the filename is unnecessary, however. Just run "fossil open" on the repository file once and from there on out any fossil command in that directory will run against said repo.
      - zaarn 9y ago
        >Just run "fossil open" on the repository file once and from there on out any fossil command in that directory will run against said repo. During my testing I never encountered that command much, though it doesn't really relieve the problem of having to double-open a repository; open folder, then open repo. When I change a directory in Git, it automatically `fossil open`'s the current repo. If no repository file is specified there should be an automatic fallback. Or even better, make using a non-default repo file a special flag, just like in git. I don't really want to have to deal with opening something or connecting something when changing directories should be sufficient.
dilap 9y ago
How's Fossil do with large binaries? We've got a 24GB git repo and it's...not the greatest. (Not terrible, either, but not great.)
- jaccarmac 9y ago
  Also not the greatest in my (very limited) experience. Everything is stored in one SQLite file. Thus at a certain size the problems which SQLite has with large data start to show up in your repository.
- gecko 9y ago
  In the same order of magnitude as Git. The only DVCS I’ve seen handle this well is Mercurial, and then only when you’re using all the Facebook plugins (like remotefilelog) that effectively re-centralize it. (This is also the same conceptual direction Microsoft’s going with their Git VFS; I just don’t think they’re as far along yet.) Honestly, there are times Subversion’s a fine option. If your repo is 24GB, you may be in one those times.
  - dilap 9y ago
    The pain of git at 24GB isn't too bad -- still better off than using svn, I'd say.
- dgsb 9y ago
  Did you think using git-annex or git-lfs ?
andrecl 9y ago
Is rebasing possible in fossil? I was led to believe it was difficult since the commit history was immutable.
- jimktrains2 9y ago
  Last time I had this discussion I was told it's fundamentally against the concept of fossil and that editing history is an antifeature. Also, they claim this provides assistance in meeting regulatory standards, but never saw much more than assertions on that. You could obviously edit the underlying sqlite data store if you really wanted to, but there is no UI and they consider that a feature. While I'm sure I'm coming off as judgey I can understand their points, even if I feel like it would lead to a mess at every company I've worked at. It is nice that additional things besides source can be tracked, bug requests for instance.
  - rbehrends 9y ago
    > Also, they claim this provides assistance in meeting regulatory standards, but never saw much more than assertions on that. This is probably in reference to this old message by Richard D. Hipp [1]: "Fossil, in contrast, is designed to remember everything. Fossil was specifically designed to support the DO-178B inspired development process used by SQLite, with few developers and a complete and immutable audit trail for all inputs." DO-178B, now superseded by DO-178C [2], was an FAA standard used for the approval of commercial software-based aerospace systems. [1] https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19555.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... [2] https://en.wikipedia.org/wiki/DO-178C https://en.wikipedia.org/wiki/DO-178C
  - oblio 9y ago
    svn was used successfully for many years at many companies without having the git "feature" of deleting history. svn obliterate was never implemented and if people needed something like that they would use admin hacks. It was definitely as easy as git makes it.
    - 9y ago
interfixus 9y ago
I am a cranky old contrarian. I do not like huge monopolies or monoliths. Github in itself is fine, but it rubs me the wrong way how huge and all-pervading it has become - a sort of Facebook for coders. Fossil avoids all that, and is, of course, orders of magnitude more manageable than Git. For years, I have been using it for all sorts of personal record-keeping. All sorts - code, yes, but also notes and manuscripts and sketches and what have you. Super-handy tool, with baked-in wiki and ticketing, and everything neatly packed in a single SQLite-file. Mind you, the new encrypted Git-service in Keybase is sitting there, calling my name.
- frabert 9y ago
  The only issue I have with keybase's git service is performance, right now. Otherwise, it's a godsend for personal projects you don't want to make publicly available.
- blauditore 9y ago
  I have the impression that in many people's head, Git == GitHub. There are other hosted git services, and it also not super hard to set up a repo manually, on a server or even locally. I agree Git may be too complex for some people or projects, and Fossil can fit better there. But Github is not the issue, as it can easily be avoided.
- hota_mazi 9y ago
  Look, our lives (not just software lives, our entire lives) are dominated by crappy de facto standards. They are everywhere. They imposed themselves through inertia, laziness and by virtue of being just a tad more useful than anything else at a time where everything else was terrible. Cable companies, Internet providers, social networks, foods, they surround us. But once in a while, we get stuck with a de facto standard that's actually quite good in its category. I happen to thing git is one of those. It took a while to get there, we had to suffer through decades of crappy source control systems until we eventually stumbled upon a good one. I'm happy with git. It has a terrible UI but beyond that, it's been an incredible force for progress not just in the open source world but increasingly inside companies as well. It fosters team work, encourages external contributions and once you've gotten used to its arcane flow, it enables all these aspects in pretty efficient ways. I'm happy with git. You should be too. And you should also be wary of making claims such as "Fossil is orders of magnitude more manageable than git". The burden of proof is on Fossil and beating git is a tall order.
grogenaut 9y ago
can someone explain succinctly what they like about fossil over git? I found a few overall articles but a nice HN comment would also help if anyone is game. Are there certain types of projects where it just works better for you than git?
- gecko 9y ago
  On top of the command-line user interface being much easier for most people (it’s not as orthogonal as Mercurial, but it’s much more consistent than Git’s), the ability to have bug tracking, code, and wiki in a single executable, where all assets (not just code) synchronize, makes kickstarting a new project with full hosting environment ridiculously simple.
  - flukus 9y ago
    How good are the bug tracker and wiki? My immediate reaction to this idea is to throw up in my mouth a little bit because I remember the TFS experience, everything was integrated but all the individual components were worst-in-class. I can see the value for small and/or personal projects, but beyond that is there a good reason to not use seperate best of breed tools?
    - beagle3 9y ago
      Fossil’s bug tracker and wiki mostly evolved out of cvstrac, which also inspired Trac that you are likely familiar with. It is similar to trac, more bare bones but about as functional, and infinitely faster and more responsive. It is also completely distributed; do you have a copy of your issues and discussions for the day github eats them?
    - Frondo 9y ago
      From the experience of someone who used Fossil for small and large projects (solo and in teams) for 3-4 years, they aren't very good. The bug tracker can be heavily customized, and get ready to do so, but it still has irritating limitations that are, when I checked a few years ago, WONTFIX limitations. Sending emails on bug tracker activity is one. (I've seen people talk about workarounds, like writing cron jobs to monitor the RSS feed of a fossil repo and send off an email, and, frankly speaking that is not a very good solution. It's going to be a little fragile and it's not administerable by non-scripting-savvy folks.) The wiki is also kinda wonky. Doing file attachments is weird, or was when I used it, the markup is non-standard (not mediawiki, not markdown), etc. The worst part is, while I can learn to work around the various oddities that basically all spring from Fossil being the product of folks who don't use a lot of other tools (and consequently don't see what other tools have essentially standardized on), I can't reasonably expect my less-savvy team members to be as dedicated in learning this one tool, because, ultimately, for what? How is fossil so much better than github or whatever? It didn't get us any farther, except now people have to learn some quirky new interface stuff. Day-to-day, zero benefit.
xelxebar 9y ago
The idea of hosting issues along with the repo seems intriguing. Does anyone have experience doing the same with git? Seems like some people are doing it: https://github.com/duplys/git-issues https://github.com/duplys/git-issues
- fsiefken 9y ago
  some people use an org-mode file as issue list, but then non-developers cannot easily view or add issues to the list unless you set them up with an easy to use org-mode (web?) editor/viewer.
- dgsb 9y ago
  If I recall correctly, having looked for such solutions in git a few years back, most of bug tracker management in a git repository project were either uncompleted or unmaintained.
- chriswarbo 9y ago
  I use Artemis in my personal projects: http://www.mrzv.org/software/artemis http://www.mrzv.org/software/artemis It works with mercurial and git. I like the fact it's very simple and straightforward: - Issues are maildirs in `.issues`, named with hashes - The original description and subsequent comments are messages in those maildirs - Metadata like status, severity, etc. are headers on the description message There are simple commands to list, show, add and close issues. That's it. If you want a UI to browse issues, just point any mail reader at `.issues`. If you want a UI to input issues or comments, just set your EDITOR or VISUAL env var to either a text editor or an email editor (I use both: Emacs with `message-mode` ;) ). If you want a Web UI, just use any maildir renderer (I use mhonarc).
- WorldMaker 9y ago
  I've been waiting for one to include seamless sync with GitHub Issues, and haven't yet felt enough itch to scratch that project together myself.
krylon 9y ago
I like Fossil very much. It is compact, yet offers a nice variety of features. I especially like the integrated web interface and the fact that the Wiki, with its entire editing history is transmitted along the regular file operations on the repo whenever a repo is cloned or pulled. (I use Fossil to track the source tree of scripts, little programs and SQL queries I write at work, and of my personal "monorepo" at home where all of my toy projects live. I.e. I have not done anything big with fossil, but for smaller repos it has served me very, very well.) Also, on Windows it is just a single, statically-linked executable, so "installing" it is as simple as copying the executable into a folder that is in your %PATH%. I am sure Git supports a lot of advanced use cases that Fossil does not, but for my needs, it is pretty close to perfect. One feature I do miss the ability to copy a file along with its version history up to that point. It is not super important, but sometimes it would be helpful if one could see that a given file started its life as a "fork" of another file.
- loxs 9y ago
  Try reposurgeon
SQLite 9y ago
Author of the referenced wiki post, and of SQLite and Fossil here... The other day, I had 60 minutes of free time between events and so I brainstormed a few ideas for improving Fossil while sitting in a Starbucks, and those unedited, spur-of-the-moment notes trigger a big discussion on HN... Yikes! I do appreciate the feedback. Seriously. Your comments are very, very helpful. But let's not attach too much weight to my musings over coffee. Should I interpret the response here to mean that there is latent demand for a new-and-improved VCS in the world. Does this mean that Git is ripe for disruption? Some Issues I Have With Git (1) A Git repository is a pile-of-files and/or a bespoke key/value store (packfiles). The format of the repository is underdocumented. (Proof sketch: try to write a utility that reads content out of a git repository without first studying the git source code.) The repository format is also brittle, as evidenced by the difficulty the Git developers have had trying to add support for hash algorithms other than SHA1. (2) The key/value design of Git limits the information you can extract from the repository. Example: It is difficult to find the descendants of a check-in in Git - so difficulty that nobody ever does it. You can find ancestors easily, but finding all the descendants of a check-in is very hard. In addition to depriving the user of useful information, the inability to find descendants of a check-in leads directly to the "disconnected head" problem. That one deficiency is a show-stopper for me. And this is but one example of the limitations imposed by the key/value design of Git. (3) For people who don't want to put their trust in GitHub, setting up a Git server is way too difficult. (4) Git requires the user to remember too much state information. Git users should be cognizant of (a) the current check-out, (b) the "index" or staging area, (c) the local head, (d) the local copy of the remote head, and (e) the actual remote head. The more mental power users must to devote to keeping track of Git, the less there is available to work on their own code. (5) Git only allows one check-out per repository. (I am told there are resent extensions to git to try to address this deficiency, but I am also told they do not work very well.) (6) Git does not do a good job of remembering branch history. In particular, branches are unnamed in Git. (7) Git is for file versioning only. Other important project information, such as bug tracking, must be handled separately. Fossil is an effort to address the problems above. I do not claim that Fossil is perfect, just that it is better than Git. I am keen to make Fossil even better. Your feedback is appreciated.
- peatmoss 9y ago
benmccann 9y ago
I would love if SCMs made it easier to have access controls. E.g. I want to give a contractor access to a single file or directory. That's basically impossible with git
aquamo 9y ago
I use fossil for small projects and I often import trees from GitHub into fossil-scm to visualize and reason about the history. I really appreciate the mindset that Dr. H and friends have brought to both SQLite and Fossil - that is - minimal and efficient code with very low dependencies. I first came across fossil-scm when I was looking for a simple way to host some development repos for a small group; it is so much easier with the integrated cli/server than what I found with git. Also, I love the ease of setting up replication and the he single file format. Keep up the good work, glad to see there is some focus on the next generation! I'd like to second the feature request mentioned elsewhere in this thread about having some for of access control on sub-trees or files within a fossil project - but - maybe that could be accomplished by simply doing a separate project / vendor tree type pattern IDK.

208 points by Fice 9y ago

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

petre 9y ago
Kind of hard and rather useless to pack most of Github's functionaliy in an 1Mb standalone binary. The web UI is adequate and works really well. Git does not come with a web UI of its own and the CLI is quite arcane compared to fossil. We've been happily using fossil for at least three or four years. It gets the job done without getting in the way. I'd really like to use fossil-ng on git and hg repos. That way I don't have to touch git ever again.
- xwattt 9y ago
  > web UI is adequate https://www.fossil-scm.org/index.html/timeline?y=ci https://www.fossil-scm.org/index.html/timeline?y=ci Adequate for what? That is just a mess of unimportant info.
  - SQLite 9y ago
    > https://www.fossil-scm.org/index.html/timeline?y=ci https://www.fossil-scm.org/index.html/timeline?y=ci ... That is just a mess of unimportant info. That screen contains all and only the information I want to see. (No surprise, since I wrote that screen.) I would very much like to read more details from Xwattt about what he (or she) finds messy, unimportant, and inadequate about the timeline view of Fossil and to perhaps see examples of better presentations of development history. I wonder if Xwattt has tried clicking on two of the check-in circles in the graph from the link above, in order to get a diff between the two selected check-ins? Is that information not useful? What of the filtering options in the sub-menu? Is clicking on "Files" to see all the individual files changes in each check-in not helpful? Is clicking on a branch-name tag to see a timeline of just that one branch not something that other people ever want to do? Seriously - I'm not trolling here. I honestly what to grok what it is that Xwattt finds inadequate about the Fossil web interface, as understanding this will help to make the interface better.
    - Frondo 9y ago
      Do you use Github or Bitbucket regularly? That would be the best way to understand what people are used to, and consequently what they will expect to see (or not see). If the reply is, "fossil is meant to be different," then of course you have your answer; it shows you what you care about, not what people who are accustomed to other systems care about.
    - petre 9y ago
      I use both fossil and github. I find fossil's history graph more useful than github's commits view which is basically just a git log and only lists one branch at once. In fossil I can see all checkins on all branches simultaneously. If I want to see a signle branch I click on it. If I want to see a diff, I click on the checkin link.
    - xwattt 9y ago
      > contains all and only the information I want to see http://noisydecentgraphics.typepad.com/design/images/2008/03/11/yourproduct.jpg http://noisydecentgraphics.typepad.com/design/images/2008/03... > examples of better presentations Here it is - http://github.com/ http://github.com/ > Is that information not useful? Sure, all information useful, but presentation and usability of fossil ui is near zero. It looks like a programmer without any aesthetic taste just throw all information in random places on screen just to fill it. While UX designers polishes every checkbox, padding and font size. For example - why unreadable commit ids occupy so much space on the screen? When I open timeline - I want to read commit descriptions first, and only after that I may be interested in some commit id. I'm opening github timeline and I'm focused on commit descriptions, but fossil timeline accents me on useless commit ids! > I'm not trolling here Me too. I bet 99% of Github success is a good UX - but it is very difficult for programmer to understand it.
    - ptrott2017 9y ago
      As a long time user of Fossil who periodically tries to persuade others to use it, the challenges I have seen getting others to adopt fossil that echo XWattts comments include: Look and feel. I have tried different UI themes - github and stackoverflowesque (so-skin.txt) are the most successful in getting buys in - but out of the box fossil, tends not to get a great initial response and it is suprising how many people just stop there. Fossil timeline graph is different from Github commit view - which is the main tool many of devs I work have only used. I much much prefer Fossil graph view to Github commits I find it a lot more helpful, but others do not see it this way. This can usually be quickly solves with some on boarding training, but it is a small initial barrier friction point to adoption. Tickets and timeline - Actual user feedback said while trying to get a colleague to use Fossil -" In tickets and timeline - Whats this weird jumble of letters i have to click on - why can I not click on the ticket title?" While obliviously all tickets need a unique identifier - do i need to look at it all the time, or can I reveal it only when i need it? This is comes up frequently. One of the biggest barriers to adoption that has prevented me getting adoption in wider teams is - as silly as this sounds - not directly scm functionally related but user experience on connected items for tickets. I personally love the fact I can have issues and docs in same repo as code - it was one of the first things that attracted me to Fossil and has proven itself on my own projects repeatedly. However I loose people every time I bring up the issues page up because its not how many teams work today - they use tools with a Kanban interface that connects or is associated to their repo. I was very excited to Steve Landers initial work (http://www.eurotcl.tcl3d.org/eurotcl-2016/presentations/EuroTcl2016-Landers-KanbanTcl.pdf http://www.eurotcl.tcl3d.org/eurotcl-2016/presentations/Euro...) in this direction - but that seems to have not progressed into Fossil core - i hope it does (or something like it) go into Fossil-NG. Last but not least and not web interface but workflow related is CI integration. I now know Ron Perrella developed a Jenkins plugin (see https://github.com/rjperrella/jenkins-fossil-adapter https://github.com/rjperrella/jenkins-fossil-adapter ) but when this question came up - I did not have an answer and could not find anything on the home page etc. I like using Fossil - its easy to use and has a great feature set but the above are some of the issues that I have seen that caused folks to stop looking at it and go back to other tools they use today.

exikyut 9y ago

This is absolutely awesome. I barely use Git myself - my use cases have pretty much been https://xkcd.com/1597/ https://xkcd.com/1597/ - but the two main features I have needed to use are --depth=1 (to download just recent files) and "just fetch this one file from this one directory". --depth=1 occasionally breaks repos because of the way Git works. I THINK (don't cite!) that Git stores submodule information in the master repo's history. So when I do a depth=1 clone with something that has submodules, I literally don't receive the metadata about the submodule information. But now the local history I do have is borked, and the only way to really fix it is to rm -rf the destination and start again. But it's typically directories with submodules that also have massive histories. Like ffmpeg, for example. Yay. -- Git doesn't have a "just grab me this one file or directory over there" option. It would probably be possible, but would probably be a massive hack to implement without even considering the internal architecture of Git - I don't know how the packfile format works (been meaning to find out one of these days) but it does seem that it shoves multiple files into the same packfile databases. -- Finally, I am really happy to hear that Fossil-NG is somehow (?!?) going to be able to import Git repositories. I never wanted to learn Git - I've been trucking along like the XKCD above, but somewhere along the way I realized that it just wasn't the superior architecture and was glad I'd never adopted it. At some point I hope to learn Fossil and Mercurial, with Git a begrudging afterthought. I love how Git is referred to not once but twice as a _legacy_ client xD

sigjuice 9y ago
I have not tried it, but the one-liner to fetch a single file that is mentioned here https://stackoverflow.com/a/14610427/78720 https://stackoverflow.com/a/14610427/78720 seems plausible
ketralnis 9y ago
> Finally, I am really happy to hear that Fossil-NG is somehow (?!?) going to be able to import Git repositories If I'm understanding what you mean it's been able to do that for a long time, bidirectionally https://www.fossil-scm.org/xfer/doc/trunk/www/inout.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/inout.wiki
iveqy 9y ago

xellisx 9y ago

I was hoping this was about the old FOSSIL driver.

ketralnis 9y ago

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

boris 9y ago
>I've had to answer the "why not just use github?" question a lot of times. We have a FAQ entry for that: https://build2.org/faq.xhtml#github https://build2.org/faq.xhtml#github
- bch 9y ago
  This is excellent. Addressing cargo cult development with its own self. GitHub == git, git == awesome because Linux and Linus, Linux development communications == email (turntable scratch noise)
- hota_mazi 9y ago
  > Mostly because we want complete control of our infrastructure. That's certainly a good reason to stay away from github but a terrible reason to roll your own infrastructure. How about using a hosted gitlab instance? It's been progressing extremely quickly and even has features that github doesn't have yet. You get the best of both worlds: git and being your own master. > I am much more efficient using my mail client (mutt) and text editor (emacs) than a web browser form. That's a surprisingly myopic view point. Of course, you are entitled to your preferences but if you take your project seriously, you need to realize that the choice of an arcane bug tracking system means that most users will simply never file bugs for your project, let alone fix them and then update your bug tracking system. You are most likely facing a huge opportunity cost here and you might never have realized it, even if you might be tempted to answer that you have received bugs against your project. Think again: how many users were about to and then just gave up when they saw you use non standard tools? This is really a simple choice: whose life are you trying to make easier, yours or your users'?

ComputerGuru 9y ago

I think what the world really needs is just a better cli/porcelain for git starting with better and clearly defined terminology built around how people actually use git and not how libgit represents its data. I’ve toyed with the idea of making my own mostly-compatible interface but I wouldn’t want to be using a non-upstream syntax (especially if I’m the only one using it).

giancarlostoro 9y ago
I've found Source Tree to be fine to use. It's a GUI but it uses actual git names so trying commands isn't as scary. Other clients make up names and sometimes hide a lot of the magic to a scary dangerous level also harder for someone to tell me what to do and me to follow what they mean vs just doing it on Source Tree. Just wish it ran on Linux.
krylon 9y ago
The use of the word "porcelain" for the user-facing parts of git always makes me cringe or giggle, because the first association that comes to my mind is a toilet (as opposed to tableware). And just to be clear, my opinion of Git is nowhere near that low. I do not like it very much, but I do not despise it, either. I know it is silly, but I cannot help myself. Sorry.
- cesarb 9y ago
  It's not silly, it's the correct analogy. "We divide Git into high level ("porcelain") commands and low level ("plumbing") commands." (https://git-scm.com/docs/git#_git_commands https://git-scm.com/docs/git#_git_commands) The "porcelain" is the user-visible part, the "plumbing" (hidden within the walls) is the behind-the-scenes part. Originally, the "porcelain" commands were shell scripts wrapping the "plumbing" executables (written in C). (Possibly relevant: "[...] When asked why he called the new software, "git," British slang meaning "a rotten person," he said. "I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git." -- https://www.pcworld.idg.com.au/article/129776/after_controversy_torvalds_begins_work_git_/ https://www.pcworld.idg.com.au/article/129776/after_controve...)

spdegabrielle 9y ago

Amazing engineering. The UI is 1999 - but that shouldn’t distract you from the engineering inside. That said, all the pieces are there to add a modern web UI with very little effort.

yjftsjthsd-h 9y ago
> That said, all the pieces are there to add a modern web UI with very little effort. Any idea how hard to just inject some css?
- gecko 9y ago
  It’s extremely easy; there’s an entire concept of themes, and it’s trivial to switch amongst them. Somewhere I’ve got a GitHub-circa-2012 theme for it just to mess with people.
  - oso2k 9y ago
    I’d be interested in seeing that.
    - petre 9y ago
      http://fossil.include-once.org/fossil-skins/index http://fossil.include-once.org/fossil-skins/index
      - xwattt 9y ago
        Please, never share this link again! My eyes...
      - gecko 9y ago
        Hah, yep, that looks exactly like it. I forgot how horrid it looked.
udba 9y ago
The UI being 1999 is a positive. The website has nothing it doesn't need. There's a Dieter Rams quote on this topic. As an example, switching between folders in the source tree feels faster than it does using Explorer. This is what the web should be.

developuh 9y ago

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

petre 9y ago
There is Chisel but it's just a hosting service for Fossil. You don't get any kind of added value other than not having to host it yourself.
dognotdog 9y ago
That's the beauty of fossil... you hardly need one! Most aspects (wiki, issues) those services offer can be in the local repo, always accessible.
- jimktrains2 9y ago
  I use GitHub to have a publicly accessible, discoverable, and searchable presence for the repo. Perhaps we should build something like gnu social (or diaspora, but not as bad) for code projects, or build on existing distributed social networks.
  - zaarn 9y ago
    This is somewhat in the works. There is an issue on GitLab to enable federated pull requests and I believe Gogs/Gitea community is working on getting some sort of standard figured out if I'm not mistaken.
    - sytse 9y ago
      Issue for reference https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 https://gitlab.com/gitlab-org/gitlab-ce/issues/4013
- hinkley 9y ago

maxpert 9y ago

From article: > This allows, for example, a Fossil-NG user to clone and use a repository out of GitHub while continuing to use the superior Fossil user interface. I totally disagree here; I don't think Fossil user interface is superior at all!

jaccarmac 9y ago
Are you talking about the command line porcelain? If so that's certainly true, but Fossil really shines when you use its web UI as part of your VCS use cycle. And there's certainly room for additional porcelain as the repository format is a well-documented SQLite file.
- zaarn 9y ago
  Personally, I don't like either. I've found the CLI to be rather confusing, especially since there is no default SQLite filename so I can just go without having to type it all the time (that was last time I tried it). The Web UI doesn't fare better and it somewhere on the lower half of my UX shitlist.
  - jaccarmac 9y ago
    Fair enough on most points. Have to point out typing the filename is unnecessary, however. Just run "fossil open" on the repository file once and from there on out any fossil command in that directory will run against said repo.
    - zaarn 9y ago
      >Just run "fossil open" on the repository file once and from there on out any fossil command in that directory will run against said repo. During my testing I never encountered that command much, though it doesn't really relieve the problem of having to double-open a repository; open folder, then open repo. When I change a directory in Git, it automatically `fossil open`'s the current repo. If no repository file is specified there should be an automatic fallback. Or even better, make using a non-default repo file a special flag, just like in git. I don't really want to have to deal with opening something or connecting something when changing directories should be sufficient.

dilap 9y ago

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

jaccarmac 9y ago
Also not the greatest in my (very limited) experience. Everything is stored in one SQLite file. Thus at a certain size the problems which SQLite has with large data start to show up in your repository.
gecko 9y ago
In the same order of magnitude as Git. The only DVCS I’ve seen handle this well is Mercurial, and then only when you’re using all the Facebook plugins (like remotefilelog) that effectively re-centralize it. (This is also the same conceptual direction Microsoft’s going with their Git VFS; I just don’t think they’re as far along yet.) Honestly, there are times Subversion’s a fine option. If your repo is 24GB, you may be in one those times.
- dilap 9y ago
  The pain of git at 24GB isn't too bad -- still better off than using svn, I'd say.
dgsb 9y ago
Did you think using git-annex or git-lfs ?

andrecl 9y ago

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

jimktrains2 9y ago
Last time I had this discussion I was told it's fundamentally against the concept of fossil and that editing history is an antifeature. Also, they claim this provides assistance in meeting regulatory standards, but never saw much more than assertions on that. You could obviously edit the underlying sqlite data store if you really wanted to, but there is no UI and they consider that a feature. While I'm sure I'm coming off as judgey I can understand their points, even if I feel like it would lead to a mess at every company I've worked at. It is nice that additional things besides source can be tracked, bug requests for instance.
- rbehrends 9y ago
  > Also, they claim this provides assistance in meeting regulatory standards, but never saw much more than assertions on that. This is probably in reference to this old message by Richard D. Hipp [1]: "Fossil, in contrast, is designed to remember everything. Fossil was specifically designed to support the DO-178B inspired development process used by SQLite, with few developers and a complete and immutable audit trail for all inputs." DO-178B, now superseded by DO-178C [2], was an FAA standard used for the approval of commercial software-based aerospace systems. [1] https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19555.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... [2] https://en.wikipedia.org/wiki/DO-178C https://en.wikipedia.org/wiki/DO-178C
- oblio 9y ago
  svn was used successfully for many years at many companies without having the git "feature" of deleting history. svn obliterate was never implemented and if people needed something like that they would use admin hacks. It was definitely as easy as git makes it.
  - 9y ago

interfixus 9y ago

I am a cranky old contrarian. I do not like huge monopolies or monoliths. Github in itself is fine, but it rubs me the wrong way how huge and all-pervading it has become - a sort of Facebook for coders. Fossil avoids all that, and is, of course, orders of magnitude more manageable than Git. For years, I have been using it for all sorts of personal record-keeping. All sorts - code, yes, but also notes and manuscripts and sketches and what have you. Super-handy tool, with baked-in wiki and ticketing, and everything neatly packed in a single SQLite-file. Mind you, the new encrypted Git-service in Keybase is sitting there, calling my name.

frabert 9y ago
The only issue I have with keybase's git service is performance, right now. Otherwise, it's a godsend for personal projects you don't want to make publicly available.
blauditore 9y ago
I have the impression that in many people's head, Git == GitHub. There are other hosted git services, and it also not super hard to set up a repo manually, on a server or even locally. I agree Git may be too complex for some people or projects, and Fossil can fit better there. But Github is not the issue, as it can easily be avoided.
hota_mazi 9y ago
Look, our lives (not just software lives, our entire lives) are dominated by crappy de facto standards. They are everywhere. They imposed themselves through inertia, laziness and by virtue of being just a tad more useful than anything else at a time where everything else was terrible. Cable companies, Internet providers, social networks, foods, they surround us. But once in a while, we get stuck with a de facto standard that's actually quite good in its category. I happen to thing git is one of those. It took a while to get there, we had to suffer through decades of crappy source control systems until we eventually stumbled upon a good one. I'm happy with git. It has a terrible UI but beyond that, it's been an incredible force for progress not just in the open source world but increasingly inside companies as well. It fosters team work, encourages external contributions and once you've gotten used to its arcane flow, it enables all these aspects in pretty efficient ways. I'm happy with git. You should be too. And you should also be wary of making claims such as "Fossil is orders of magnitude more manageable than git". The burden of proof is on Fossil and beating git is a tall order.

grogenaut 9y ago

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

gecko 9y ago
On top of the command-line user interface being much easier for most people (it’s not as orthogonal as Mercurial, but it’s much more consistent than Git’s), the ability to have bug tracking, code, and wiki in a single executable, where all assets (not just code) synchronize, makes kickstarting a new project with full hosting environment ridiculously simple.
- flukus 9y ago
  How good are the bug tracker and wiki? My immediate reaction to this idea is to throw up in my mouth a little bit because I remember the TFS experience, everything was integrated but all the individual components were worst-in-class. I can see the value for small and/or personal projects, but beyond that is there a good reason to not use seperate best of breed tools?
  - beagle3 9y ago
    Fossil’s bug tracker and wiki mostly evolved out of cvstrac, which also inspired Trac that you are likely familiar with. It is similar to trac, more bare bones but about as functional, and infinitely faster and more responsive. It is also completely distributed; do you have a copy of your issues and discussions for the day github eats them?
  - Frondo 9y ago
    From the experience of someone who used Fossil for small and large projects (solo and in teams) for 3-4 years, they aren't very good. The bug tracker can be heavily customized, and get ready to do so, but it still has irritating limitations that are, when I checked a few years ago, WONTFIX limitations. Sending emails on bug tracker activity is one. (I've seen people talk about workarounds, like writing cron jobs to monitor the RSS feed of a fossil repo and send off an email, and, frankly speaking that is not a very good solution. It's going to be a little fragile and it's not administerable by non-scripting-savvy folks.) The wiki is also kinda wonky. Doing file attachments is weird, or was when I used it, the markup is non-standard (not mediawiki, not markdown), etc. The worst part is, while I can learn to work around the various oddities that basically all spring from Fossil being the product of folks who don't use a lot of other tools (and consequently don't see what other tools have essentially standardized on), I can't reasonably expect my less-savvy team members to be as dedicated in learning this one tool, because, ultimately, for what? How is fossil so much better than github or whatever? It didn't get us any farther, except now people have to learn some quirky new interface stuff. Day-to-day, zero benefit.

xelxebar 9y ago

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

fsiefken 9y ago
some people use an org-mode file as issue list, but then non-developers cannot easily view or add issues to the list unless you set them up with an easy to use org-mode (web?) editor/viewer.
dgsb 9y ago
If I recall correctly, having looked for such solutions in git a few years back, most of bug tracker management in a git repository project were either uncompleted or unmaintained.
chriswarbo 9y ago
I use Artemis in my personal projects: http://www.mrzv.org/software/artemis http://www.mrzv.org/software/artemis It works with mercurial and git. I like the fact it's very simple and straightforward: - Issues are maildirs in `.issues`, named with hashes - The original description and subsequent comments are messages in those maildirs - Metadata like status, severity, etc. are headers on the description message There are simple commands to list, show, add and close issues. That's it. If you want a UI to browse issues, just point any mail reader at `.issues`. If you want a UI to input issues or comments, just set your EDITOR or VISUAL env var to either a text editor or an email editor (I use both: Emacs with `message-mode` ;) ). If you want a Web UI, just use any maildir renderer (I use mhonarc).
WorldMaker 9y ago
I've been waiting for one to include seamless sync with GitHub Issues, and haven't yet felt enough itch to scratch that project together myself.

krylon 9y ago

I like Fossil very much. It is compact, yet offers a nice variety of features. I especially like the integrated web interface and the fact that the Wiki, with its entire editing history is transmitted along the regular file operations on the repo whenever a repo is cloned or pulled. (I use Fossil to track the source tree of scripts, little programs and SQL queries I write at work, and of my personal "monorepo" at home where all of my toy projects live. I.e. I have not done anything big with fossil, but for smaller repos it has served me very, very well.) Also, on Windows it is just a single, statically-linked executable, so "installing" it is as simple as copying the executable into a folder that is in your %PATH%. I am sure Git supports a lot of advanced use cases that Fossil does not, but for my needs, it is pretty close to perfect. One feature I do miss the ability to copy a file along with its version history up to that point. It is not super important, but sometimes it would be helpful if one could see that a given file started its life as a "fork" of another file.

loxs 9y ago
Try reposurgeon

SQLite 9y ago

Author of the referenced wiki post, and of SQLite and Fossil here... The other day, I had 60 minutes of free time between events and so I brainstormed a few ideas for improving Fossil while sitting in a Starbucks, and those unedited, spur-of-the-moment notes trigger a big discussion on HN... Yikes! I do appreciate the feedback. Seriously. Your comments are very, very helpful. But let's not attach too much weight to my musings over coffee. Should I interpret the response here to mean that there is latent demand for a new-and-improved VCS in the world. Does this mean that Git is ripe for disruption? Some Issues I Have With Git (1) A Git repository is a pile-of-files and/or a bespoke key/value store (packfiles). The format of the repository is underdocumented. (Proof sketch: try to write a utility that reads content out of a git repository without first studying the git source code.) The repository format is also brittle, as evidenced by the difficulty the Git developers have had trying to add support for hash algorithms other than SHA1. (2) The key/value design of Git limits the information you can extract from the repository. Example: It is difficult to find the descendants of a check-in in Git - so difficulty that nobody ever does it. You can find ancestors easily, but finding all the descendants of a check-in is very hard. In addition to depriving the user of useful information, the inability to find descendants of a check-in leads directly to the "disconnected head" problem. That one deficiency is a show-stopper for me. And this is but one example of the limitations imposed by the key/value design of Git. (3) For people who don't want to put their trust in GitHub, setting up a Git server is way too difficult. (4) Git requires the user to remember too much state information. Git users should be cognizant of (a) the current check-out, (b) the "index" or staging area, (c) the local head, (d) the local copy of the remote head, and (e) the actual remote head. The more mental power users must to devote to keeping track of Git, the less there is available to work on their own code. (5) Git only allows one check-out per repository. (I am told there are resent extensions to git to try to address this deficiency, but I am also told they do not work very well.) (6) Git does not do a good job of remembering branch history. In particular, branches are unnamed in Git. (7) Git is for file versioning only. Other important project information, such as bug tracking, must be handled separately. Fossil is an effort to address the problems above. I do not claim that Fossil is perfect, just that it is better than Git. I am keen to make Fossil even better. Your feedback is appreciated.

peatmoss 9y ago

benmccann 9y ago

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

aquamo 9y ago

I use fossil for small projects and I often import trees from GitHub into fossil-scm to visualize and reason about the history. I really appreciate the mindset that Dr. H and friends have brought to both SQLite and Fossil - that is - minimal and efficient code with very low dependencies. I first came across fossil-scm when I was looking for a simple way to host some development repos for a small group; it is so much easier with the integrated cli/server than what I found with git. Also, I love the ease of setting up replication and the he single file format. Keep up the good work, glad to see there is some focus on the next generation! I'd like to second the feature request mentioned elsewhere in this thread about having some for of access control on sub-trees or files within a fossil project - but - maybe that could be accomplished by simply doing a separate project / vendor tree type pattern IDK.