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.
This is genuinely just my two cents; please don't value it more than that.
I was very active in the Mercurial community for a long time, and I'm still using it for personal stuff today. Mercurial solves issues 1, 2, 4, 5, and 6 in your list. I'm mentioning that for only one reason:
That was not enough.
My personal theory on why this happened largely centers around network effects. Git got big in Ruby at the same time GitHub came into existence, and I think that drove the adoption as much as anything. Ignoring whether people here feel that Git was better or not, the simple fact is that it did not matter: GitHub used Git, and the community used GitHub, so you used Git. The network effects in that kind of situation can be really hard to defeat. And while it's possible that solving items 3 and 7 will make the difference, I don't think that'll do the trick unless you can come up with a strong way to defeat GitHub's (and Git's) incumbent network effects.
I (with my background on the Mercurial crew back in the day) definitely think Git is ripe for disruption -- I've done some thinking on things you could do.
(1) Good UX -- steal more from Mercurial here. No "index" or staging area by default, or at least a way to disable it. Being smoother about branch handling between local and remotes would also help significantly IMO.
(2) Network protocol and probably on-disk compatibility with Git and maybe Mercurial -- essential to gaining adoption.
(3) Better support for binary files, perhaps through using a modern content-defined chunking mechanism like FastCDC.
(4) Good support for narrow and shallow clones, maybe even making new clones (somewhat) shallow by default.
(5) Write it in Rust with a good modular architecture: good (including startup) performance, safe/robust and easier to reuse key parts (see also Facebook's Mercurial server stuff in Rust). The lack of a coherent/reusable architecture in Git has also been a key reason AFAICT that Git and Facebook are investing in Mercurial-based tooling.
(6) Use the inotify/FSEvents/whatever the windows equivalent is APIs to keep a daemon and have much faster status responses plus potentially record every change to the files on-disk -- sort of like Git's reflog, on steroids. Could also do smart build system integration here?
(7) Better support for very large trees (a la bup's midx extension to Git's storage format). It should really support Google/Facebook monorepo scale.
I have thought about starting something like this -- but I'm not sure this is the kind of thing where crowdfunding would afford me to build it out; and also not sure the big tech players would be willing to fund something like this (if they are, let me know though!).
I think the items that really have potential to address pain-points & be killer-features that motivate people to move beyond git will are (3) and (7) (big files and big trees).
The rest are probably nice, but are more incremental improvements than something that's going to justify the huge leaving-the-standard-platform cost.
Side note:
Regarding good UX, I very much agree that git's command line is insane, and makes it unnecessarily hard for people to understand.
However, I would disagree that the staging area is a bad idea! It's one of my favorite git features. I think it's just git's extremely confusing command-line terminology and shitty information display that it seem confusing.
As a small piece of evidence in favor of this view, I'll say that I recently introduced a tech artist to git using the (extremely good!) GitUp app. He had no problem picking it up right away, including staging, committing, pushing, making branches & merging.
I think this is because the excellent GitUp UI represents the concepts in such a nice visual way that they become very clear.
First off, thank you for all your work on behalf of Earth.
I am not as familiar with Fossil, but it seems that one use case Fossil may be well positioned to address, is the storage and revision of data sets along with data analyses.
For people working with any significant quantity of data, git was a backslide as compared to svn. For people wanting to do reproducible research, git does a great job storing the code, but the data assets must be stored out-of-band if they aren’t tiny.
Any thoughts as to how Fossil might or might not address that use case?
EDIT: I should add that, in addition to data uses, I’ve heard tell that git isn’t great for storing art assets along with code (e.g. video game development)
These all sound great (except for (4) -- I think this mirrors the underlying reality and is good), but I'm not sure if any would be killer features.
One thing I think would be a killer feature (though I'm not even sure if it's possible):
Supporting large binary assets in the repo without slowly down terribly.
I'm pretty sure that would be enough to get many people to switch. From there, you might see a network effect as people that didn't even care about that grew to like your other points of improvement, and eventually Fossil could overthrow git and becoming the reigning VC champion.
> It is difficult to find the descendants of a check-in in Git - so difficulty that nobody ever does it. [..] That one deficiency is a show-stopper for me.
This is interesting. In my using git I haven't ever needed to look at descendants. Perhaps that's just because the limitation is deeply established in my mind (git is really the only VCS I've used). How might this information be helpful in normal usage?
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.
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.
“Orders of magnitude” is probably out of line, and there’s always the case for “horses for courses” (or “tool for the job”, more broadly), but to say git is better than what appeared before (cvs, svn) could be interpreted as both true and useless. Pretty much any distributed source control management (DSCM) software is what modern development is using today, and better than the previous decades tools (cvs, svn). Git is but one example in the DSCM field. You mention it has a terrible UI, and I’m inclined to agree. The workflow might be described as terrible too, and maybe it’s a contributor to the UI. Git probably became what it is to a large extent because of the cult of personality of Linus, despite git itself. Sure it’s better than CVS, but in defence of GP post, it’s not unreasonable to push back because “good enough” (git) is standing in the way of “good” (fossil). That all said, cult or not, git has its network effect now, which is a powerful thing no matter what ones opinion of git is. I suspect we’re really probably remarkably in agreement wrt how fortunate we are in the code management field, and we should all be grateful, but that doesn’t preclude asking for more from our tools. We are privileged to be in a world where a fossil or mercurial, or bitkeeper user can “fall back” to git. We otherwise have an embarrassing amount of good choices for capable version control. Indeed, a good time to be alive.
This is one of the examples of well thought of, well written and in general excellent observations on the status of things in our lives. Well done sir!
> I'm happy with git. You should be too.
This is the only part of your comment I don't agree with. Just because you (and me too) are happy with git, that doesn't mean we should be advising other people to be happy with them. Let everybody decide for themselves what they should be happy about and if by some chance their unhappiness produces something even better, we all win again.
> 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.
I agree that git is pretty nice, and ubiquity is an important feature. For example, if you choose git you'll find loads of tooling, documentation, infrastructure, etc. that supports it. If you encounter a problem using it, there's almost certainly a fix or a detailed "won't fix" explanation in a blog post or on StackOverflow.
> I'm happy with git. You should be too.
Making git a de facto standard has won a VCS battle, but not the war; there's no reason to be complacent.
It's fine to not care too much about VCS: just test the waters every now and again to make a quick cost/benefit assessment of the options; right now, that probably says "just use git". The majority of users should take this approach, and spend their time and effort on improving other things they care more about.
Yet it's also fine to still care about VCS, try to invent or improve things, add more tooling or integrations for whatever non-standard system, and promote those things in order to nudge those cost/benefit analyses a little. If something becomes compelling enough, a feedback loop could make it the new de facto standard.
Whilst I'm not particularly excited by Fossil, I am by other VCS ideas like the "patch theory" used by Darcs ( http://darcs.net ). A major problem with Darcs is poor time-complexity, but enough people cared about the idea to make Pijul ( https://pijul.org ) which doesn't have this problem.
Does that make Pijul better than git? No, not least because of the project's immaturity and lack of tooling, integration, etc. Yet it nudges the cost/benefit a little, which might encourage more of those who care about VCS (say, those writing integration plugins) to support it, which nudges the cost/benefit a little more, and so on :)
I disagree with the "progress" part. Git is still the 2005 state of the art, and in parts not even that (it took until 2015 to even support something as basic as multiple checkouts of the same repository via `git worktree`).
Git is generally not very suitable for new features, because the repository format is very restrictive and has no room for adding new metadata (it's not impossible, but it's always going to be a hack).
Most actual progress in version control has happened in systems other than Git, both open source and commercial (what Git has gotten is a lot more polish and ecosystem integration).
My general criticism of Git isn't that it's bad, but that it's the lowest common denominator of modern version control and has resulted in technology being locked in to yesterday's state. At the same time, it's awfully complicated for how relatively basic its feature set is. It is not a bad tool, but it's not a particularly attractive one, either.
Also:
> It took a while to get there, we had to suffer through decades of crappy source control systems until we eventually stumbled upon a good one.
Umm, what? Git wasn't the first attempt at improving upon CVS or SVN, and was arguably in some aspects worse than some of its predecessors (it often had higher implementation quality, but in terms of features it was also often a step backwards). I think lots of people are not familiar with PRCS (including the specced-out, but never implemented PRCS2), GNU arch, Monotone, or Darcs, not counting commercial or more esoteric ones.
This is a very vague statement, and contradicts your original claim. The way objects and branch references was set up by git-new-workdir was completely safe for git-gc not to lose other workdir's data. Other than that, keeping copies on another computer is the only way to reliably protect against data loss in any VCS system.
> The way objects and branch references was set up by git-new-workdir was completely safe for git-gc not to lose other workdir's data.
The simplest example is when the only live reference to a commit is a detached HEAD. Because HEAD is duplicated per workdir, other workdirs do not know about HEAD, and if it doesn't refer to an actual ref, it's subject to garbage collection.
This isn't much of a risk if there's constant ongoing work (because then the GC grace period and the reflog will typically save you), but it can be a problem if you're dealing with a branch that sees only intermittent work.
Even without that, it's pretty easy to destroy graph ancestry (which is not actual repository content, but still fairly important metadata). Example:
set -e
git init g
cd g
echo 1 >foo
git add foo
git commit -m test
cd ..
sh git-new-workdir g g2
cd g2
git checkout -b foo
echo 2 >foo
git commit -a -m foo
git branch -d master
cd ../g
echo 3 >foo
git commit -a -m master
git log --graph --all
The above script will disconnect one branch from the rest of the repository.
The underlying problem is that there are some important invariants that Git needs to maintain to ensure repository integrity in the presence of mutable history, and if part of the information is held in a place that it does not know about, it may not be able to maintain those invariants.
There's a reason why `git worktree` goes to a lot more effort to prevent such scenarios by registering worktrees with the repo and why `git worktree lock` is still needed.
> Other than that, keeping copies on another computer is the only way to reliably protect against data loss in any VCS system.
That’s not the point of GP post. In fossil for example, one can have multiple checkouts of a single repository (on a single computer by the same person) without fear this will lead to data loss. I don’t think this was suggested as a backup strategy, just a workflow feature.
I most certainly didn't claim it was the point of GGP either. The point was that no evidence at all have been put forward that git-new-worktree is less "data safe" than the corresponding fossil solution, on the contrary on the design level it seems designed to be safe to use. So it seems GGP didn't mention it because it didn't fit their narrative that git lacks features.
At the same time I can't claim it is guaranteed to be "no data loss" because I didn't review all the code. If you are strongly concerned about data loss you would probably use backups, _regardless_ if you use git, fossil etc.
The sad part about Mercurial is that it is losing the battle against git because it was the better tool at the outset.
The well-documented shittyness of the git user experience was the key to its success because it forced the creation of shiny wrappers and integrations to hide the abomination within. And this combination of gloss and peer pressure now manages to convince people that git is "good".
Personally (as a member of the Mercurial crew at the time) I believe GitHub has been a key part of Git winning. It provided a great UX for sharing code that Bitbucket despite valiant efforts of Jesper et al could just not match.
I do think the time is just about right for someone to start a new generation that has compatibility with Git but provides a better user experience. Also in this category, see the Breezy effort that some old-time Bazaar hackers have started:
Considering how the hype cycle proceeds, any switch to a git successor will probably be slow. I would expect a replacement that comes into existence now to need five years to make itself known in the market and another five years to gather a critical mass. The actual tipping point would probably be reached around 15 to 20 years from now. That is an awfully long time.
I'm with you on a lot of points. But not really a huge believer in being told what I should and shouldn't do.
'Orders of magnitude' refers to a) the built-in web-interface and the bundled tools, b) the self-contained and super-easily compiled executable, and c) the one-file repository, consistency guaranteed, which I can stuff in my pocket and do with as I please.
I think that git is quite good, but I don't like the notion of 'squashing commits': when you squash commits you loose history!
I would prefer to have a "fold/folder" of commits which could be manipulated as 'one commit' but would instead be a set of commit and you could look inside the folder if you need the full history.
Like everything, "squashing commits" has good use cases and bad use cases. They have all been documented to death but just as a quick reminder:
Bad: squashing commits that have been pushed. Very bad. Not just because it rewrites history but because it's going to cause headaches to other people.
Good: squashing commits in your own local branch before pushing to origin. In my opinion, this is not just good, it's excellent. Nobody on my team needs to know how many micro commits or dead ends and backtracks I've gone through before I reached the current shape of the code I'm about to push. I love squashing in this situation so I can rearrange and make the commit more pretty before it becomes public.
On top of that, I'd argue that this kind of commit squashing contributes to making better commit logs.
In Fossil the good use case is supported by using private branches: when you merge a private branch into a public branch, only the merge commit is pushed, the private branch remains private.
That's largely a UI issue. Look at Bazaar's hierarchical logs, for example [1]. I call it largely a UI issue because:
1. You can run `bzr log` on a git repository (with the bzr-git plugin). Hence it's a UI issue.
2. That operation still takes O(history size) time, because git repositories lack the necessary metadata to make the operation fast (hence: "largely" a UI issue).
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.
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.
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
> 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'?
At the moment the post I’m replying to is in the grey, perhaps because it comes off as aggressive.
But the underlying claim is true.
Filing a bug report takes effort, including: reproducing the bug, doing my best to isolate the circumstances in which it occurs, checking for existing reports of the same issue, and (if none are found) writing up as clear a report as possible. It creates a social obligation to follow up on responses from the maintainers, especially if I want to encourage them to pay attention and fix the bug. In particular, that may involve delving into the design of the code and figuring out the true nature of the problem, or what a proper fix would look like - which is almost invariably more complicated than it initially appears. And for all that, it generally comes with no guarantee that the bug will be fixed or even the report looked at. Even if the bug is fixed, it usually won’t be fixed quickly enough to obviate the need for me to work around it or deal with it somehow. In other words, filing the report probably won’t help me much; I do it more for the benefit of anyone else who runs into the same problem in the future.
I get a sense of satisfaction from filing good bug reports, but it’s enough effort,for little gain, that it takes very little to make me lose interest and go spend time on something else instead. In the case of build2, I’m not even unfamiliar with mailing lists - I run a mailman instance myself - but I don’t regularly contribute to any projects that handle bug reports over email, so it would be an unfamiliar process, which is more than enough of an ‘obstacle’. I’d also get mildly stressed out thinking about the proper etiquette for mailing lists (should there be a greeting?), although that’s more of a personal quirk. And then there are the “posting guidelines”…
Other people may be less socially inhibited than me, but then, a lot of people have much less experience with mailing lists than me (e.g., for many, exactly zero).
Thus, regardless of what ought to be true or what’s reasonable or fair to maintainers, in practice, I strongly suspect that any given bug in build2 has a lower chance of being reported than it would have with a more GitHub-like process. (That may or may not actually equate to actual missed bug reports, because the community seems to be small enough to make for a low sample size.)
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)
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.
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.
Maybe a better option is to convince people like DigitalOcean to provide a prebuilt image.
But I’m not sure I agree with the conclusion here
You do need the network effect if you want git gone. GitHub is just easy enough to cross reference bugs in other repositories your project depends on.
There's chiselapp.com, but one of fossil's strengths is you don't need that kind of service. Just drop the fossil binary anywhere convenient and off you go.
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.
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.
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.
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.
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/Euro...) in this direction - but that seems to have not progressed into Fossil core - i hope it does (or something like it) go into Fossil-NG.
Last but not least and not web interface but workflow related is CI integration. I now know Ron Perrella developed a Jenkins plugin (see https://github.com/rjperrella/jenkins-fossil-adapter ) but when this question came up - I did not have an answer and could not find anything on the home page etc.
I like using Fossil - its easy to use and has a great feature set but the above are some of the issues that I have seen that caused folks to stop looking at it and go back to other tools they use today.
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.
This is absolutely awesome. I barely use Git myself - my use cases have pretty much been 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
When using --depth=1 with submodules, git tries to clone a submodule. Let's say its master branch to the depth of 1. However the super project does not point to a branch but to a sha1, so except when the master branch points to sha1, it will fail.
Most often you can get away with --depth=100 or something like that, but what's really needed is a way to fetch a sha1 and not only branches and tags. This is however not as easy at it seems, since only sha1 that are accessible from any tag or branch should be allowed for fetching (otherwise we've a security hole).
I'm not sure if this is implemented in git yet, and I'm not sure if all git hosting providers support it.
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.
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).
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.
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)
The "porcelain" is the user-visible part, the "plumbing" (hidden within the walls) is the behind-the-scenes part. Originally, the "porcelain" commands were shell scripts wrapping the "plumbing" executables (written in C).
(Possibly relevant: "[...] When asked why he called the new software, "git," British slang meaning "a rotten person," he said. "I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git." -- https://www.pcworld.idg.com.au/article/129776/after_controve...)
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.
You've missed the point of fossil. It's not just a version control tool, it's also an issue tracker, code review tool and a wiki and it's all distributed. You can do code reviews and manage issues offline.
I'm hoping for someone to implement these with git-notes. Code review is already covered by git-appraise, but issue tracking and some kind of wiki would be nice. I know there are projects that are working on this but none that are very far.
Git's UI may not be great but I'm already used to it and it doesn't bother me.
> I totally disagree here; I don't think Fossil user interface is superior at all!
Have you even used it? I'm using both fossil and git and I find fossil's CLI and integrated documentation vastly susperior to git's in terms of usability.
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.
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.
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.
>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.
It's inconvenient for sure, but to be clear opening a repository is a one-time operation. It puts a file called ".fslckout" in the current directory which acts like the ".git" directory does for Git.
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
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.
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.
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.
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:
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).
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.
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.
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?
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.
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?
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.
I think your critique of the usability of the tools is completely spot-on, but I wanted to note one thing you reminded me about here:
> The bug tracker can be heavily customized, and get ready to do so, but it still has irritating limitations that are, when I checked a few years ago, WONTFIX limitations. Sending emails on bug tracker activity is one.
The modern Fossil versions can be compiled with real Tcl for scripting, rather than just TH1, which makes solving this problem, and a pile of other automation-centric issues, very trivial--at least if you don't mind coding in Tcl. (NB, you only need to do this on the central server, for obvious reasons; everyone else can just use the off-the-shelf binaries.)
The rest of your comment completely stands, and is why I don't actually use Fossil.
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?
Serious question: can you point me to the unorthogonal features of git? I personally never had an issue with it but maybe I only need some hints to see them.
> can someone explain succinctly what they like about fossil over git?
Think of basic github functionality packed in a stand alone, self-hosting binary with a really good CLI and integrated help, ticketing, users and web interface to manage most of that, do diffs, create zip/tar archives, patches, change repo properties. It can also work in a client/server fashion, somewhat similar to subversion, but it's a distributed VCS instead so every client and server retains a full copy of the repository. The repository is replicated instead of sharded, so if you clone it you've got all the branches, all the tickets, everything but the unversioned content, the users, the settings and the css themes. Thus, your backups are equal to the number of clients in the event that you somehow manage to damage the repo on the server (which is just a repo where everyone syncs). It's also very easy to pick up without much wading through the manuals, something I always find myself doing when using git. Every command has a `fossil help <command>`. Most of the functionality is also usable through the web interface. It just works seamlessly on multiple platforms.
> Are there certain types of projects where it just works better for you than git?
Smaller projects, as in not Linux kernel sized. Projects where you don't throw a myriad of binaries in the VCS; there's the `unversioned` command for that. Projects where you have a relatively stable team, not a lot of random outside collaborators like on most succesful opensource projects on github. Projects where you'd want to self host or maybe keep private. I also use it on servers for configuration versioning.
It gets really slow if you dump large files in it. That was the drop that made me switch to git. Otherwise I used fossil for my own little tinkering for years.
* Single file repository with proper transactional semantics (it's an SQLite DB) rather than a "pile of files" implementation. I can trivially and safely copy the repository, send it as a mail to a new collaborator, etc.
* Fossil is a single executable. Unlike Git or Mercurial, that makes installation trivial.
* The whole system is remarkably clean, simple, and lacking in cruft. This also makes it easy to explain and get people started.
* Fossil has a well thought-out system for tags and named branches; they are persistent, but can be renamed. This is different from Git, where history tends to be largely a soup of anonymous objects, and Mercurial, where it is impossible to rename branches.
* It comes with a built-in wiki and distributed ticketing system. If you want to self-host rather than rely on GitHub/Bitbucket, that's already a very useful feature.
* `fossil undo` is very useful, even though it supports only one level of undo.
* The ability to store and share unversioned files is often very convenient.
Things I don't like about Fossil:
* The console interface is sometimes too simplistic for some commands (`fossil timeline` is one of the biggest offenders); it errs in the opposite direction from Git and relies on a GUI too much for basic operation (though I'd still prefer it over Git, but not necessarily other VCSes). That said, you can script it fairly adequately either with the JSON interface or even through direct SQL queries if you don't mind investing the time.
* The workflow for external contributions for contributors without commit access is more cumbersome than necessary; in principle, `fossil bundle` serves that need, but it lacks some features (you can't bundle non-commit artifacts, for example).
* Commit messages all get squished into a single line of output. You could argue that wiki pages or technotes are the proper way to document more complex information (so you don't have to sift through commit messages), but it's difficult to relate them to a specific commit and they aren't supported by `fossil bundle`, as mentioned above. There's some unfinished work on attaching remarks to commits [1], but this work seems dormant.
* Scalability is even more of a problem than with other distributed version control systems if you're dealing with really big repositories (not that those other systems necessarily cover themselves in glory, either), though the situation has improved in recent years.
Only with a fair amount of pain (basically, `fossil merge --cherrypick`, then `fossil purge` for the original branch).
That's because mutable history is not part of the normal workflow that's being encouraged by fossil. You will see that "wrong" branches are simply tagged as "mistake" in the Fossil or SQLite repositories [1]. Branches are merged rather than rebased and the web UI is built around the assumption of having branches as distinct, named entities, rather than having them coalesced into the mainline. Fossil also uses autosync by default, where commits are automatically pushed to the master repository, which further discourages changing history.
If you simply want a local checkpointing mechanism (where you snapshot revisions at intervals with the intent to later combine them into a single meaningful commit), that's what private branches or `fossil stash snapshot` are for. Commit metadata, such as commit messages, can be changed later, but the edits leave an audit trail.
A major reason here is specifically that changes are supposed to always have an audit trail.
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.
> 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.
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.
It also comes from how git is used. With git small commits are possible. It's nice to be able to manage those and build larger, coherent ones. Also, because of the distributed nature, sometimes rewriting is useful to fix mistakes.
However, yes, that is not the only possible workflow. SVN and CVS have been used on very large projects with moderate success. SQLite development is done in fossil. It's not impossible to do it correctly with immutable history.
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.