Fossil(fossil-scm.org)
fossil-scm.org
Fossil
https://fossil-scm.org/home/doc/trunk/www/index.wiki
136 comments
> Does Fossil have a unique or killer feature that makes it a good alternative to git, other than "simpler to use"?
If you click on the link it lists a ton of additions to git. The first bullet lists "bug tracking, wiki, forum, email alerts, chat, and technotes" none of which are supported by git.
Then again, bullet 4 is "Self-host Friendly" (every git client is also a full git server -- after all it's fully distributed) and bullet 5 is "Simple Networking - Fossil uses ordinary HTTPS (or SSH if you prefer)" Pretty sure git supports https out of the box these days (though I don't use it -- ssh is so much simpler).
So yes, I would call those killer features for those who want them, and are pretty unique to any revision control system I've used, though some centralized sites have encrusted git with those features. Having them distributed sounds like a good idea.
If you click on the link it lists a ton of additions to git. The first bullet lists "bug tracking, wiki, forum, email alerts, chat, and technotes" none of which are supported by git.
Then again, bullet 4 is "Self-host Friendly" (every git client is also a full git server -- after all it's fully distributed) and bullet 5 is "Simple Networking - Fossil uses ordinary HTTPS (or SSH if you prefer)" Pretty sure git supports https out of the box these days (though I don't use it -- ssh is so much simpler).
So yes, I would call those killer features for those who want them, and are pretty unique to any revision control system I've used, though some centralized sites have encrusted git with those features. Having them distributed sounds like a good idea.
> Then again, bullet 4 is "Self-host Friendly" (every git client is also a full git server -- after all it's fully distributed)
Sure, for code. But fossil distributes issues and wiki the same way, which makes comprehensive self hosting much easier.
Sure, for code. But fossil distributes issues and wiki the same way, which makes comprehensive self hosting much easier.
Bullet 2, “Built-in Web Interface”, is also not quite something that makes Fossil stand out as opposed to Git, because most installations of Git come with gitweb[1]. It's not the pinnacle of modern web-design, sure, but if you just want to browse a repo through a web interface, it's perfectly fine.
[1]: https://git-scm.com/docs/gitweb
[1]: https://git-scm.com/docs/gitweb
Yeah, in the case of Git, the web ui is very simple, as Git only cares about code. In the case of Fossil, the web ui is extensive, as Fossil stores all types of data, not just code.
As an interesting example, the very website in this submission (fossil-scm.org) is in fact just a standalone Fossil website, running as you'd run your own repository. Everything that is on that website, is something you get for free for each repository you use Fossil for.
As an interesting example, the very website in this submission (fossil-scm.org) is in fact just a standalone Fossil website, running as you'd run your own repository. Everything that is on that website, is something you get for free for each repository you use Fossil for.
Fossil is more self-host friendly if you're on a shared hosting plan, since it works via CGI and can be served via nginx/Apache with minimal configuration. Every git hosting solution I'm aware of requires a dedicated daemon.
> The first bullet lists "bug tracking, wiki, forum, email alerts, chat, and technotes" none of which are supported by git.
Oh, so systemd of SCM world?
Also, making moving out of it extra hard by embracing everything.
Oh, so systemd of SCM world?
Also, making moving out of it extra hard by embracing everything.
Fossil imports and exports git
https://fossil-scm.org/home/doc/tip/www/inout.wiki
https://fossil-scm.org/home/doc/tip/www/inout.wiki
I’m not sure the “extra batteries included” line is very persuasive.
It’s open to objections: first, Github does this already, so it’s a solved problem. Second, lack of focus. Why would VCS experts be good at designing a compelling forum or ticketing system?
A more compelling selling point, which is buried in the docs, is the use of SQLite as storage. Apparently this makes it easy to traverse a commit’s descendants, which git struggles with.
It’s open to objections: first, Github does this already, so it’s a solved problem. Second, lack of focus. Why would VCS experts be good at designing a compelling forum or ticketing system?
A more compelling selling point, which is buried in the docs, is the use of SQLite as storage. Apparently this makes it easy to traverse a commit’s descendants, which git struggles with.
> It’s open to objections: first, Github does this already, so it’s a solved problem
No, you're misunderstanding the feature (or they don't explain it well). GitHub solves the problem on their platform yes, but not in the protocol (git) itself.
Fossil embeds that data in the repository, all the data is local. Fossil works perfectly with the "local first" doctrine, something Git also does, but not for everything around Git, that Fossil embeds into the repository.
Basically, Fossil is Git + GitHub but self-hosted and offline first. You pull down a Fossil repository is like pulling down the Git repository + all related GitHub data.
> Why would VCS experts be good at designing a compelling forum or ticketing system?
They don't have to be experts about something to make it good enough. For a lot of us with poor internet connectivity, the offline first doctrine is essential in a lot of the work we do, as internet can disappear at any notice. Fossil works much better for this, as I can still read the wiki and tickets when my internet drops, while if I were using GitHub, I'd have to results to writing my own code/use 3rd party software to get the same experience.
No, you're misunderstanding the feature (or they don't explain it well). GitHub solves the problem on their platform yes, but not in the protocol (git) itself.
Fossil embeds that data in the repository, all the data is local. Fossil works perfectly with the "local first" doctrine, something Git also does, but not for everything around Git, that Fossil embeds into the repository.
Basically, Fossil is Git + GitHub but self-hosted and offline first. You pull down a Fossil repository is like pulling down the Git repository + all related GitHub data.
> Why would VCS experts be good at designing a compelling forum or ticketing system?
They don't have to be experts about something to make it good enough. For a lot of us with poor internet connectivity, the offline first doctrine is essential in a lot of the work we do, as internet can disappear at any notice. Fossil works much better for this, as I can still read the wiki and tickets when my internet drops, while if I were using GitHub, I'd have to results to writing my own code/use 3rd party software to get the same experience.
I don't find these arguments persuasive. My point was that if I want wiki, ticketing etc., I can get it right now on an industry standard platform. Yes, I get that they embed it in the software itself. So what? Suppose someone said "our new operating system includes a web browser". But I already have a web browser? "Yes, but we embed it in the kernel itself!" Why would that be compelling?
The other argument, that this is needed for offline use, is more meaningful. I don't personally think this is a big enough deal to be the USP. But sure, for some people it may be.
The other argument, that this is needed for offline use, is more meaningful. I don't personally think this is a big enough deal to be the USP. But sure, for some people it may be.
> It’s open to objections: first, Github does this already, so it’s a solved problem.
I can buy the reasoning that it's a solved problem with additional software, but citing github specifically here is absurd.
Github is a SaaS, centralised, closed source and unfederated platform.
I can understand that you think they're a good service, but there's a huge difference between something like git (which is a tool and a flexible one) and SVN, vs a hosted service.
You can think of it like VLC media player vs youtube.
I can buy the reasoning that it's a solved problem with additional software, but citing github specifically here is absurd.
Github is a SaaS, centralised, closed source and unfederated platform.
I can understand that you think they're a good service, but there's a huge difference between something like git (which is a tool and a flexible one) and SVN, vs a hosted service.
You can think of it like VLC media player vs youtube.
Sure. If you think everything centralized, closed source and federated should be replaced with something decentralized, federated and open source, then Github is unacceptable. Just note that these are not inherently features. They may at some point become useful features - if e.g. all closed source software eventually is exploited by monopolists - but that is a very particular viewpoint. Given the success of Github, it seems that many people don't yet share that view. So, if I were persuading people to use Fossil, I would try to focus on features that most people want. But OK, if it's going for a free software niche, then fine.
I like it for projects which may need to live a really long time between changes. Having a single .fossil file containing the entire project, it's history, documentation, and tickets in a set location makes it simple to pick something back up after x years. The optional web UI is simple HTML that is unlikely to break in future browsers. Finally, fossil is typically distribed as a single static binary, which makes it easy to install/update.
If I was to have to build a VCS from source decades from now to get to my repo, I believe that fossil will be much simpler than git (which has a fair amount of build dependencies).
Other commenters are talking about GitHub/Discord/Jira etc but I think that's missing the point a bit - in 20 years time are those closed sass services still going to exist? If they are, is your project still going to be there? And will you remember which flavour of the month sass you used for tickets?
If I was to have to build a VCS from source decades from now to get to my repo, I believe that fossil will be much simpler than git (which has a fair amount of build dependencies).
Other commenters are talking about GitHub/Discord/Jira etc but I think that's missing the point a bit - in 20 years time are those closed sass services still going to exist? If they are, is your project still going to be there? And will you remember which flavour of the month sass you used for tickets?
> Does Fossil have a unique or killer feature that makes it a good alternative to git, other than "simpler to use"?
Fossil is basically GitHub itself stuffed inside the DVCS. Issues and the wiki are stored alongside the code.
Fossil is basically GitHub itself stuffed inside the DVCS. Issues and the wiki are stored alongside the code.
While there are a few differences in operating principles, probably 90% of the baseline knowledge required to use Git is the same as with Fossil (and Mercurial for that matter). If you already know Git, you can learn Fossil in less than 30 minutes, and IME there is very little context switching cost if using multiple VCSs.
In that sense, I don't believe Git has a knowledge lock in, because it is easy for anyone to switch or to simultaneously use available alternatives. It's all about the ecosystem, and really, Github.
In that sense, I don't believe Git has a knowledge lock in, because it is easy for anyone to switch or to simultaneously use available alternatives. It's all about the ecosystem, and really, Github.
One thing you can do with Fossil that you can't with Git is use the tickets database as a distributed, version controlled sqlite database, complete with user authentication, and trivially add extensions using CGI.
> trivially add extensions using CGI
Can you elaborate on this please?
Can you elaborate on this please?
Documentation here: https://fossil-scm.org/home/doc/trunk/www/serverext.wiki
I suggest taking a look at https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki
I have never used, but I’m interested in trying… maybe some personal project in the future :)
I have never used, but I’m interested in trying… maybe some personal project in the future :)
The big ticket item is obviously that Fossil includes all the stuff that people constantly whine about being locked into Git{hub,lab} over, e.g. issues, as part of the tool rather than some external vendor-specific thing you have to worry about separately.
Also, as someone who really liked Monotone before git won, having your whole repo in a single file is just nice for the same ops-related reasons it’s refreshing to be able to download and run a self-contained binary rather than needing an installer or whatever.
Also, as someone who really liked Monotone before git won, having your whole repo in a single file is just nice for the same ops-related reasons it’s refreshing to be able to download and run a self-contained binary rather than needing an installer or whatever.
A killer-feature measure is not very useful way of selection, as it's not how projects select a VCS - many projects/teams have individual requirements which affect such feature considerations.
In my somewhat simplified view, Git's 'killer-feature' by now is simply its ubiquity.
By the same token, for Fossil's this could be claimed as a single binary that does it all.
Just download the binary, and you've got the ubiquitous set of project-related facilities: VCS/tickets/docs/wiki/team/forum/chat with simple aporoach to sync and self-host.
In my somewhat simplified view, Git's 'killer-feature' by now is simply its ubiquity.
By the same token, for Fossil's this could be claimed as a single binary that does it all.
Just download the binary, and you've got the ubiquitous set of project-related facilities: VCS/tickets/docs/wiki/team/forum/chat with simple aporoach to sync and self-host.
> In fact pretty much the only chance you have of avoiding git would be to build your own stuff on something else, hire/collaborate only with others who share the same view, and never interact with basically any other open source
I worked with a guy once who took a principled stand against git and (almost) exclusively interacted with the org's git repos through Hg-Git: https://hg-git.github.io/
I worked with a guy once who took a principled stand against git and (almost) exclusively interacted with the org's git repos through Hg-Git: https://hg-git.github.io/
Did he ever explain to what his issue with git was and why he took a stand against it?
I helped him resolve a really gnarly octopus merge through git once and we had a nice chat about it.
A. He liked Mercurial more, although I forget all his reasonings. Mercurial's commands are definitely better named, no contest.
B. He hated that git was "winning" and so tried to help prolong Mercurial's lifespan by writing plugins and helping out in the ecosystem.
A. He liked Mercurial more, although I forget all his reasonings. Mercurial's commands are definitely better named, no contest.
B. He hated that git was "winning" and so tried to help prolong Mercurial's lifespan by writing plugins and helping out in the ecosystem.
If you are a professional developer git is an essential skill, and will be for the foreseeable future.
But that doesn’t make git or fossil right for every project.
Fortunately you can easily switch between them.
See https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...
But that doesn’t make git or fossil right for every project.
Fortunately you can easily switch between them.
See https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...
It’s fantastic for personal projects. The ticket system is highly customisable, I usually set it up a bit like a todo list. It’s super easy to self host.
(Yes I obviously still use Git as well)
(Yes I obviously still use Git as well)
I also use the Fossil issue system as a todo list. Feels "more real" than listing things in a spreadsheet.
> In fact pretty much the only chance you have of avoiding git would be to build your own stuff on something else
This is a strange thing to say. It's like saying the only chance you have of avoiding python is to use something else.
> never interact with basically any other open source.
You don't need git knowledge to download an open source library from GitHub (there's tarballs on the web page), or to use your languages package manager, even if it speaks git under the hood (go get/npm)
> I just don't see the dominance of git changing for the next decade,
The dominance of git is real particularly in certain industries, but even now git still has terrible support for huge repositories and binary files, partial checkouts, submodules. The problem is that most projects are suited just fine to the limitations of git, (and SVN and p4 and hg), so the value comes in the supporting tooling and infrastructure. Why would I choose fossil over git when for free I can get everything that GitHub/gitlab provides for me?
This is a strange thing to say. It's like saying the only chance you have of avoiding python is to use something else.
> never interact with basically any other open source.
You don't need git knowledge to download an open source library from GitHub (there's tarballs on the web page), or to use your languages package manager, even if it speaks git under the hood (go get/npm)
> I just don't see the dominance of git changing for the next decade,
The dominance of git is real particularly in certain industries, but even now git still has terrible support for huge repositories and binary files, partial checkouts, submodules. The problem is that most projects are suited just fine to the limitations of git, (and SVN and p4 and hg), so the value comes in the supporting tooling and infrastructure. Why would I choose fossil over git when for free I can get everything that GitHub/gitlab provides for me?
All the bug tracking and wikis being integrated is amazing.
Sadly, it's not git and nobody else is using it, and I'm not a fan of using lots of nonstandard tech.
It seems to be better than Git, but there's no free hosts that are as big as Github/Gitlab, and convincing other people to switch technology is very hard.
Plus, the people obsessed with clean commit history won't like the lack of easy squash and rebase.
Sadly, it's not git and nobody else is using it, and I'm not a fan of using lots of nonstandard tech.
It seems to be better than Git, but there's no free hosts that are as big as Github/Gitlab, and convincing other people to switch technology is very hard.
Plus, the people obsessed with clean commit history won't like the lack of easy squash and rebase.
Mercurial was. A good contender for a while. I still think immutable history has some advantages.
why "was"? mercurial is still around, and perfectly usable. we use it at work and I've never had any problems with it, it's pretty much as good as git for day to day usage.
There's pretty much nowhere to host your repo now that bitbucket gave up (and outright /deleted/ all hg repos which was criminal, but that's besides the point)
The big three I know of (github, gitlab, bitbucket) are all git-only.
The big three I know of (github, gitlab, bitbucket) are all git-only.
Totally true for the "big three", but Sourcehut hosts mercurial repositories: https://hg.sr.ht/.
(Unaffiliated, but a happy user.)
(Unaffiliated, but a happy user.)
I'm glad there are some hold outs. It's a great technology it's just not been adopted as much as git. I had to learn git as most job ads specified git.
Mercurial’s tracking of the evolution of patch sets was really useful. GitHub PR’s mostly achieve that even if it’s lost at the native git level.
Honestly, I think the killer feature of Git was GitHub, and it was made popular by people wanting to use GitHub. The rest of the features were cherries on top of being able to use GitHub.
So I guess the killer feature for Fossil would be Fossil in that case, as Fossil is basically Git + GitHub but in one package, that works offline and local first.
So I guess the killer feature for Fossil would be Fossil in that case, as Fossil is basically Git + GitHub but in one package, that works offline and local first.
This is such an interesting piece of software. I recommend installing it to play around with it even if you have to intention at all of actually using it for real.
You can import an existing Git repository into it really quickly.
The app itself is built by the SQLite team, and takes full advantage of SQLite, in particular Many Small Queries Are Efficient In SQLite: https://www.sqlite.org/np1queryprob.html
You can import an existing Git repository into it really quickly.
The app itself is built by the SQLite team, and takes full advantage of SQLite, in particular Many Small Queries Are Efficient In SQLite: https://www.sqlite.org/np1queryprob.html
This is pretty much do everything but don't do them well than isolated solutions. Every components seem like pretty limited in functionality.
Why should one use that simple forum instead of Discourse? Why should one use the simple wiki than say Wiki.js?
And of course the toolings are already way behind as in there's not a single GUI client?
And it doesn't seem to have any social login, so people have to create an account instead of using GitHub logins.
Who uses it outside SQLite team?
Why should one use that simple forum instead of Discourse? Why should one use the simple wiki than say Wiki.js?
And of course the toolings are already way behind as in there's not a single GUI client?
And it doesn't seem to have any social login, so people have to create an account instead of using GitHub logins.
Who uses it outside SQLite team?
The SQLite project is much like SQLite itself, i.e. simple and as self contained as possible. Naturally this means they have to deal with the overhead of developing and maintaining a large portion of their toolchain. On the other hand they avoid the litany of problems that comes with using 3rd party tools, and those tools can be optimized for their particular needs.
> Who uses it outside SQLite team?
Tcl/Tk is the only big user of Fossil, as far as I'm aware.
> Who uses it outside SQLite team?
Tcl/Tk is the only big user of Fossil, as far as I'm aware.
I love the idea of fossil, git cli has horrible and unintuitive porcelain. There is no brain dead git undo (except for the 'well actually if you sell your soul to the reflog' folks), but ultimately, just like C and unix, git may be annoying in some ways but its inertia and ubiquity keep it going way longer than it's technical merits deserve when directly compared to competitors.
Also, fossil feels like someone built it for almost NIH reasons, which I freely admit is just my outsiders impression, but it feels to me like the tcl community tends to dogfood themselves a lot for cultural reasons.
But fossil is already more complete and battle tested than anything this lowly amateur will accomplish in his career.
Also, fossil feels like someone built it for almost NIH reasons, which I freely admit is just my outsiders impression, but it feels to me like the tcl community tends to dogfood themselves a lot for cultural reasons.
But fossil is already more complete and battle tested than anything this lowly amateur will accomplish in his career.
As for NIH, kinda a bit but not really. Fossil was first released in 2006, Git in 2005 (mercurial in 2005 as well). At this point in time, there was no clear "DVCS" (distributed version control system) winner yet.
The author of Fossil is drh, who is a lot more famous for being the author of sqlite (who also happens to be a major player in the TCL community). If I remember correctly[0], Fossil was written a) to dogfood sqlite (fossil uses sqlite) and also b) to get something able to not just do the VC part for sqlite, but tightly integrated issue tracking, docs, rel-eng, etc in one single system, as well as some VC-related features not present in git/mercurial and other competitors of the time (and in many cases not available in git or mercurial of today).
[0] I looked into all this new-fangled DVCS stuff back then, because it looked really interesting compared to subversion that I was using at the time, and was a pain.
The author of Fossil is drh, who is a lot more famous for being the author of sqlite (who also happens to be a major player in the TCL community). If I remember correctly[0], Fossil was written a) to dogfood sqlite (fossil uses sqlite) and also b) to get something able to not just do the VC part for sqlite, but tightly integrated issue tracking, docs, rel-eng, etc in one single system, as well as some VC-related features not present in git/mercurial and other competitors of the time (and in many cases not available in git or mercurial of today).
[0] I looked into all this new-fangled DVCS stuff back then, because it looked really interesting compared to subversion that I was using at the time, and was a pain.
Check out https://github.com/arxanas/git-branchless for `git undo` (and more)!
(arxanas shared a link to my project elsewhere in this thread :))
(arxanas shared a link to my project elsewhere in this thread :))
> Also, fossil feels like someone built it for almost NIH reasons,
Considering the rest of the SQLite development toolchain, it would be more surprising if they _didn't_ make something like fossil.
Although shunning mainstream tools like git is probably rooted in a "not invented here" attitude, I love that they bother to do so. Of course it's interesting to see what bespoke solutions they come up with, but it's amazing to see such a highly complex piece of software come with such a trivial set of dependencies. Indeed, even if it's antisocial for the SQLite devs to play in their own sandbox, the end result is nothing but increased portability for the rest of us.
Considering the rest of the SQLite development toolchain, it would be more surprising if they _didn't_ make something like fossil.
Although shunning mainstream tools like git is probably rooted in a "not invented here" attitude, I love that they bother to do so. Of course it's interesting to see what bespoke solutions they come up with, but it's amazing to see such a highly complex piece of software come with such a trivial set of dependencies. Indeed, even if it's antisocial for the SQLite devs to play in their own sandbox, the end result is nothing but increased portability for the rest of us.
> fossil feels like someone built it for almost NIH reasons
Are you aware that Git was not the first version control system? That doesn't mean Git was built for NIH reasons.
Are you aware that Git was not the first version control system? That doesn't mean Git was built for NIH reasons.
Some of the many previous threads:
https://news.ycombinator.com/item?id=28168632
https://news.ycombinator.com/item?id=27736980
https://news.ycombinator.com/item?id=26578581
https://news.ycombinator.com/item?id=24643200
https://news.ycombinator.com/item?id=21974942
https://news.ycombinator.com/item?id=19006036
https://news.ycombinator.com/item?id=17230766
https://news.ycombinator.com/item?id=15752725
https://news.ycombinator.com/item?id=13668952
https://news.ycombinator.com/item?id=12673229
https://news.ycombinator.com/item?id=10737131
https://news.ycombinator.com/item?id=8697028
https://news.ycombinator.com/item?id=3036124
https://news.ycombinator.com/item?id=2524422
https://news.ycombinator.com/item?id=809493
https://news.ycombinator.com/item?id=28168632
https://news.ycombinator.com/item?id=27736980
https://news.ycombinator.com/item?id=26578581
https://news.ycombinator.com/item?id=24643200
https://news.ycombinator.com/item?id=21974942
https://news.ycombinator.com/item?id=19006036
https://news.ycombinator.com/item?id=17230766
https://news.ycombinator.com/item?id=15752725
https://news.ycombinator.com/item?id=13668952
https://news.ycombinator.com/item?id=12673229
https://news.ycombinator.com/item?id=10737131
https://news.ycombinator.com/item?id=8697028
https://news.ycombinator.com/item?id=3036124
https://news.ycombinator.com/item?id=2524422
https://news.ycombinator.com/item?id=809493
These are not links to the discussion of the same page, but links to threads discussing various blog posts, wiki pages, etc. on the same site. It's the same thing anyone could see by clicking the domain name by the title, except without titles.
They aren't all on the same site (not that it matters), they all have significant threads and they are all about Fossil SCM, which is how 'relatedness' works on HN - by value and not by reference. If you can think of some other ones that are not on their site, you should definitely add them.
Spamming the first fifteen links from the search results for "Fossil SCM" is of no more value. This is not "how 'relatedness' works on HN", this is just clutter.
There are a lot of HN community practices I don't like so I feel your pain. For this particular trauma, though, there's a little [-] clutter-be-gone link at the end of the comment header you can use to collapse the whole thing out of the way.
It's not a community practice when it's only you doing it this way.
[deleted]
It would be good to see titles for links above. What's your point of listing them without titles?
Like the other reply points out, it's fairly standard community practice to link previous discussions for those who might be interested in checking them out. dang (the public moderator) has automated up his postings of past links so they show titles and dates but that's work and I wasn't going to do it by hand for this chonklist. The good news is, eventually, the tectonic plate of HN development will reach 'make the fancier formatting automatic for everyone':
https://news.ycombinator.com/item?id=27236708
The reply I really wanted to write was 'the point is to confuse passers by', though.
https://news.ycombinator.com/item?id=27236708
The reply I really wanted to write was 'the point is to confuse passers by', though.
It's a community effort. One person posts the links, then you come along and help out by posting the titles, then I help out by telling you what to do. Go team!
Unacceptable Ted, do all the work
Might as well just link to HN search, there you can see the titles, urls, dates, comment- and point-counter.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
I remember when there were many different reasonable options for source control. I’ve really enjoyed recent years how there’s at least one thing in software development where basically everybody agrees what the right solution to a problem is. For source control, use git. Almost nobody disagrees. Is git perfect? Of course not. Is it hard to learn? Hell yeah. But everybody does, at least enough to get by.
I find the standardization that git has brought to the industry to be wonderfully simplifying for the lives of people developing software. If only we could all agree on things like a programming language, or a database - how much more productive would we be? How many life years do we spend trying out or learning new technologies that don’t go anywhere, or which only offer marginal benefits in exchange for real sacrifices? At least for now, source control doesn’t have that level of constant churn which is so commonplace in software.
To me, the benefits of standardization on git far outweighs any benefits that might be achieved by trying something new.
I find the standardization that git has brought to the industry to be wonderfully simplifying for the lives of people developing software. If only we could all agree on things like a programming language, or a database - how much more productive would we be? How many life years do we spend trying out or learning new technologies that don’t go anywhere, or which only offer marginal benefits in exchange for real sacrifices? At least for now, source control doesn’t have that level of constant churn which is so commonplace in software.
To me, the benefits of standardization on git far outweighs any benefits that might be achieved by trying something new.
To me, it is a problem.
Only git for version control. Perfect? No. Good for everybody and every project? No. Good enough? Yes. Only UNIX for any non-GUI application, and now even worse, almost only Linux. Perfect? No. Good for everybody and every project? No. Good enough? Yes. Only C for system programming. Perfect? No. Good for everybody and every project? No. Good enough? Yes. Only x86(_64) for almost anything non-portable. Perfect? No. Good for everybody and every project? No. Good enough? Yes. (same for ARM in portable world).
We use mediocre tools which share best property: ubiquity.
World of Good Enough, world of "multi-tools" which are not perfect for any application, but good enough for almost all of them.
We lost a tons of bright systems, ideas, approaches.
Now it is common to say, that diversity and inclusivity in teams are very well for corporate culture, as each person brings his/her own point of view, and multiple point of views are better for final product or service.
But in world of modern IT tools I see opposite. Monocultures everywhere.
Sometimes I read about different IT (mostly hardware, or integraged hardwae & software) of 1985-2005 and it is very sad reading: there was a tons of different systems, approaches, architectures, languages, ways to build systems. Each and every of them were more suitable for niche tasks. And what we can see now? Linux, Docker, git, x86, C.
Yes, I know, that there is Rust and there is ARM (at least!), but it is, what, 1% of landscape? And no new or specialized OSes (even IoT, which should be hyper-effective and realtime often is built on Linux!), no new platforms which shine in one or other niche, nothing
Yes, again, I know about POWER and z/Architecture (or how it is called this month), but, again, it is drop in the ocean of same boxes with same OS.
Only git for version control. Perfect? No. Good for everybody and every project? No. Good enough? Yes. Only UNIX for any non-GUI application, and now even worse, almost only Linux. Perfect? No. Good for everybody and every project? No. Good enough? Yes. Only C for system programming. Perfect? No. Good for everybody and every project? No. Good enough? Yes. Only x86(_64) for almost anything non-portable. Perfect? No. Good for everybody and every project? No. Good enough? Yes. (same for ARM in portable world).
We use mediocre tools which share best property: ubiquity.
World of Good Enough, world of "multi-tools" which are not perfect for any application, but good enough for almost all of them.
We lost a tons of bright systems, ideas, approaches.
Now it is common to say, that diversity and inclusivity in teams are very well for corporate culture, as each person brings his/her own point of view, and multiple point of views are better for final product or service.
But in world of modern IT tools I see opposite. Monocultures everywhere.
Sometimes I read about different IT (mostly hardware, or integraged hardwae & software) of 1985-2005 and it is very sad reading: there was a tons of different systems, approaches, architectures, languages, ways to build systems. Each and every of them were more suitable for niche tasks. And what we can see now? Linux, Docker, git, x86, C.
Yes, I know, that there is Rust and there is ARM (at least!), but it is, what, 1% of landscape? And no new or specialized OSes (even IoT, which should be hyper-effective and realtime often is built on Linux!), no new platforms which shine in one or other niche, nothing
Yes, again, I know about POWER and z/Architecture (or how it is called this month), but, again, it is drop in the ocean of same boxes with same OS.
I agree with you but I don't like that I do. Needles churn is one thing, but deliberately ceasing innovation and 'settling' seems like a loss.
If we could all agree to a synchronised hype cycle that may help :)
If we could all agree to a synchronised hype cycle that may help :)
> Is it hard to learn? Hell yeah. But everybody does, at least enough to get by.
that sounds like reason to try to evolve instead kf saying "yeah well, we are done"
with some luck alternative tools come up with ideas, which become part of the default tool, maybe the default will change over time.
that sounds like reason to try to evolve instead kf saying "yeah well, we are done"
with some luck alternative tools come up with ideas, which become part of the default tool, maybe the default will change over time.
Fundamentally I don't disagree. Except that I see so much wasted effort in our industry trying to evolve just for the sake of enjoying trying new things, which I find fundamentally super inefficient. I know that's how evolution works and eventually gets to a better place. I'm just relishing the fact that for once we agree on something.
On the complexity front I have a couple perspectives. First, the fundamental concepts you need to contribute to a code base aren't that hard. Which I think is why it survives and thrives. But the CLI tools are NOT very friendly. So secondly, you might think we just need better front-ends. And maybe there are by now? But I've hated every alternative front-end to git I've ever used, but maybe that's just me. I also don't use an IDE, so I'm obviously a bit of a dinosaur by nature.
On the complexity front I have a couple perspectives. First, the fundamental concepts you need to contribute to a code base aren't that hard. Which I think is why it survives and thrives. But the CLI tools are NOT very friendly. So secondly, you might think we just need better front-ends. And maybe there are by now? But I've hated every alternative front-end to git I've ever used, but maybe that's just me. I also don't use an IDE, so I'm obviously a bit of a dinosaur by nature.
> Except that I see so much wasted effort in our industry trying to evolve just for the sake of enjoying trying new things, which I find fundamentally super inefficient
Why must it be so sufficient, with that narrow view on sufficiency. Fundamentally: If people annoy it, it is efficient in bringing joy, which in my view life should be about.
But secondly if I take the same view on efficiency: I see so much time wasted with git, so many times a repository is broken due to a bad merge or somebody doing something wrong. This can't be peak tooling.
Why must it be so sufficient, with that narrow view on sufficiency. Fundamentally: If people annoy it, it is efficient in bringing joy, which in my view life should be about.
But secondly if I take the same view on efficiency: I see so much time wasted with git, so many times a repository is broken due to a bad merge or somebody doing something wrong. This can't be peak tooling.
I kind of agree. I don't like monoculture in general, but I'm not so adverse with git.
I can remember where a place I worked used SVN, TFS, CVS and some commercial system (Perforce, I think), and it was really difficult switching between projects - I made quite a few mistakes.
Git isn't perfect, but it's more than good enough.
I can remember where a place I worked used SVN, TFS, CVS and some commercial system (Perforce, I think), and it was really difficult switching between projects - I made quite a few mistakes.
Git isn't perfect, but it's more than good enough.
Are you referring to "Git the standard format" or "Git the CLI" ? If the former, then yes I agree. If the latter, then definitely not, and I appreciate tools like Fossil & Mercurial that offer alternatives.
Some issues with "Git the standard format":
* Does not track cherry-picks
* Does not track branch names
* Tags must be unique. (You cannot add a "release" tag to every release,
for example.)
* Not easily extensible - witness the pain and years of effort trying
to move from SHA1 to SHA2.I've been using Fossil as my own personal knowledge repository for a few months, and it's been wildly successful.
It's pretty much Gitea in a single SQLite file (Wiki, tickets, version control, etc.). It's weird, but you can edit all of these things off-line and then sync everything back. `fossil ui` hosting the server for my docs locally, and from my home server is super useful and easy.
Some of the commands are super weird though, but I put them my homepage of my fossil docs :) The auto-sync feature helps since I work on multiple computers to help ensure that I don't get too far out of sync.
It's pretty much Gitea in a single SQLite file (Wiki, tickets, version control, etc.). It's weird, but you can edit all of these things off-line and then sync everything back. `fossil ui` hosting the server for my docs locally, and from my home server is super useful and easy.
Some of the commands are super weird though, but I put them my homepage of my fossil docs :) The auto-sync feature helps since I work on multiple computers to help ensure that I don't get too far out of sync.
This is actually the use case I have in mind when I think of moving my personal knowledge management system knowfox to something more enduring like fossil.
It currently is built on php/mysql with laravel with a web ui in bootstrap. This has become super annoying for a few years now because once a year or so I have to port it to a new version of laravel and cope with the new javascript framework du jour that it now promotes.
This would be fine, of course, if you run an agency which extracts money from clients for continuous upgrades, but not for a personal project.
Fossil, on the other hand, is built for longevity. It is a single executable and comes with all tools built in.
It currently is built on php/mysql with laravel with a web ui in bootstrap. This has become super annoying for a few years now because once a year or so I have to port it to a new version of laravel and cope with the new javascript framework du jour that it now promotes.
This would be fine, of course, if you run an agency which extracts money from clients for continuous upgrades, but not for a personal project.
Fossil, on the other hand, is built for longevity. It is a single executable and comes with all tools built in.
Seems like Fossil is more like an alternative to GitHub than Git. Fossil not only tracks code changes but team chat, bug tracking, wikis, etc.
Fossil is an alternative to both git (source control) and github (issues, etc).
I think its brilliant having issues tracked in fossil. Part of the promise of github is that the user is in control, since your computer is a first-class citizen of a repository. You have all the code, and all the history on your computer. You can use github, but you don't need github, since its just another node in git's distributed network.
But that promise falls apart with issues and pull requests. Issues and pull requests don't get replicated by git. If github goes down, you can't interact with issues. If github ever turns evil, or you decide you want to self host git over ssh or something, you lose the history of all your issues and conversations.
Git is a distributed, replicated data format. Why are issues fully centralized? Its bizarre - You can have a project on both github and gitlab. And you can replicate commits to both. But you can't replicate issues using the same mechanism.
Fossil is far from perfect, but I think putting the issues and stuff into the repository itself is brilliant.
I think its brilliant having issues tracked in fossil. Part of the promise of github is that the user is in control, since your computer is a first-class citizen of a repository. You have all the code, and all the history on your computer. You can use github, but you don't need github, since its just another node in git's distributed network.
But that promise falls apart with issues and pull requests. Issues and pull requests don't get replicated by git. If github goes down, you can't interact with issues. If github ever turns evil, or you decide you want to self host git over ssh or something, you lose the history of all your issues and conversations.
Git is a distributed, replicated data format. Why are issues fully centralized? Its bizarre - You can have a project on both github and gitlab. And you can replicate commits to both. But you can't replicate issues using the same mechanism.
Fossil is far from perfect, but I think putting the issues and stuff into the repository itself is brilliant.
"If [...] you decide you want to self host git over ssh or something, you lose the history of all your issues and conversations."
Github has a nice, documented API to export issues, including issue history. Many open source tools, including Gitlab, are happy to import that list into their own database:
https://docs.gitlab.com/ee/user/project/import/github.html
Granted, this has a problem if Github suddenly, without any warning, decides to turn off that API. Or if it goes down and loses data permanently. I find both of those scenarios pretty unlikely, but it you are worried about them, it should be pretty straightforward to have some sort of export script in cronjob, to keep a local copy of issue database.
Github has a nice, documented API to export issues, including issue history. Many open source tools, including Gitlab, are happy to import that list into their own database:
https://docs.gitlab.com/ee/user/project/import/github.html
Granted, this has a problem if Github suddenly, without any warning, decides to turn off that API. Or if it goes down and loses data permanently. I find both of those scenarios pretty unlikely, but it you are worried about them, it should be pretty straightforward to have some sort of export script in cronjob, to keep a local copy of issue database.
Sure; github has the ability to export its data via centrally managed APIs. My point is that tying a bunch of centralized data (access control, issues, discussions, PRs, wiki, etc) to the decentralized data store of git's source control undermines many of git's best features. It makes git a de-facto centralized system.
Centralized systems aren't bad per se, but the combination is incoherent. Github's architecture has some of the worst parts of decentralization, combined with some of the worst parts of centralization. Eg, Git's decentralized nature makes it extremely hard to evolve. (See: the desire to move from SHA1 to something more modern.) And we don't really get the benefits of a decentralized system, because I can't interact with issues while I'm offline, or while github is offline. And we're all locked in to github's ecosystem.
We can only fully interact with our opensource projects on github with permission, ironically, from Microsoft. And I don't know if I trust any big tech company enough to assume they'll remain a good stewardship over the world's opensource code.
The decentralized data store is right there in the middle of every github project. I wish github thought to use it.
Centralized systems aren't bad per se, but the combination is incoherent. Github's architecture has some of the worst parts of decentralization, combined with some of the worst parts of centralization. Eg, Git's decentralized nature makes it extremely hard to evolve. (See: the desire to move from SHA1 to something more modern.) And we don't really get the benefits of a decentralized system, because I can't interact with issues while I'm offline, or while github is offline. And we're all locked in to github's ecosystem.
We can only fully interact with our opensource projects on github with permission, ironically, from Microsoft. And I don't know if I trust any big tech company enough to assume they'll remain a good stewardship over the world's opensource code.
The decentralized data store is right there in the middle of every github project. I wish github thought to use it.
Well, Github did use decentralized data storage -- the wikis are implemented as directories full of markdown files. You can clone it to your PC and view locally, push/pull the changes, etc... In addition, you can use your repository as wiki directly -- with markdown rendering, and "edit" button in web UI, just having "docs/" full of .md files gives you pretty passable wiki.
But it seems that very few people care. How many people mirror wikis of their favorite projects, or backup their issues? I know only one such person, myself.
I think that for some types of data, distributed model with operations like "clone with full history", "pull", "merge", etc... makes very little sense. For example access control -- why would you ever want to clone this? If I set up a mirror of repo, I don't want to give their authors access by default. Same goes for discussions -- for a good discussion you want all members to see their own replies. Having original post appear on sites A, B, C; and reply 1 on sites A, B while reply 2 appears on sites B, C will be super confusing to users, and will likely just cause platform to be abandoned. And a lot of times, ticket list is better off shared, so people can coordinate the work they do even if they have their own fork.
Once you realize a lot of supporting services need to be centralized, all you can use "git" for is for data distribution. Is git better than SMTP for mailing list discussions? Is git better that SMTP / REST API for ticket list? Maybe, maybe not. But ultimately it does not matter, because most people do not care about mirroring stuff locally, and those who do care, can already achieve it.
But it seems that very few people care. How many people mirror wikis of their favorite projects, or backup their issues? I know only one such person, myself.
I think that for some types of data, distributed model with operations like "clone with full history", "pull", "merge", etc... makes very little sense. For example access control -- why would you ever want to clone this? If I set up a mirror of repo, I don't want to give their authors access by default. Same goes for discussions -- for a good discussion you want all members to see their own replies. Having original post appear on sites A, B, C; and reply 1 on sites A, B while reply 2 appears on sites B, C will be super confusing to users, and will likely just cause platform to be abandoned. And a lot of times, ticket list is better off shared, so people can coordinate the work they do even if they have their own fork.
Once you realize a lot of supporting services need to be centralized, all you can use "git" for is for data distribution. Is git better than SMTP for mailing list discussions? Is git better that SMTP / REST API for ticket list? Maybe, maybe not. But ultimately it does not matter, because most people do not care about mirroring stuff locally, and those who do care, can already achieve it.
That's true. People imagine GitHub provides git, but that's the wrong way of seeing it. They do provide it on your server but the git running on your own computer is from the git project. GitHub does help significantly with the git project, though.
Here's git's official website, which is very good, and was started by a GitHub cofounder, but is run by the git project rather than GitHub: https://git-scm.com/
Here's git's official website, which is very good, and was started by a GitHub cofounder, but is run by the git project rather than GitHub: https://git-scm.com/
You're overstating the risks a bit and it's not great to posit implausible motives and means for bad outcomes... Like, Fossil devs could "turn evil", and ship an update that destroys your museum and any copies it can find. Github could "turn evil" without notice, and permanently nuke all of someone or some org's accounts for no good reason and yes, that'd catch a lot of people with their pants down. It's better to first focus on outcomes, not means. Of course anyone actually concerned about losing their github issue data (or having their museums corrupted) should at least be making backups. (And it's not exactly an implausible outcome on its own, you can think of a variety of means that achieve it and discover one may be rather more likely for your situation, like if I was a Russian in Russia right now I'd have already made arrangements in case GH changes their mind or is legally forced to drop the ban hammer.)
The desire to move off github (and therefore any additional services besides hosting you were using, which issues are just one -- new ones keep getting added to try and cement your dependence) is something more worthwhile of thought than the idea of github turning evil. Fortunately that desire is an actual thing that's very common, or at least the desire to not be wholly dependent, and is why many people don't even use github issues to begin with even if they use github itself for hosting (or some other non-issues features). So there's not a big problem, and even if you start with using github issues, there are various migration tools to move github issues out to [alternative]. (And of course github issues have their own merits, people frequently want to switch to them! So similar migration tools exist to move from [alternative] to github issues, I wrote one for Jira years ago.)
It is brilliant to integrate things with the decentralized source control itself, you get free backups and deciding to migrate to something different in the future is easy, I think it's an overlooked approach for a lot of people. (It seems less overlooked when it comes to documentation in various forms like developer-focused .md files, or broader full static html websites which github can conveniently host for you.) Fossil is well-worth investigating for this free integration to see if it meets one's needs. But of course nothing stops you from doing it with git yourself in various ways. For personal projects, I'm pretty satisfied with being as minimal as having an issues.md file and moving things to an issues-closed.md file when I close one. I've also used the git-issue extension (https://github.com/dspinellis/git-issue -- see also its bottom section of Related Work).
But despite its brilliance it's not always the right approach. It's very easy and reasonable to want more than what is realistic for something deeply integrated with the source code itself to provide, if only for inherent conflicts of desire, let alone any question of manpower. There are very good reasons to have entirely separate (and even multiple-of-kind partially overlapping/integrating/cross-referencing) systems for source code management, issue tracking, code review, forums, IM communication, wikis, public websites, docs (of whatever kinds and types for various audiences and authors, or public or not, or team-level spikes or plannings or retrospectives)... One aspect of Fossil I found weak was its user capabilities (https://fossil-scm.org/home/doc/trunk/www/caps/ -- no custom user categories alone is a deal breaker for so many things) but flaws in the execution of a fully integrated thing isn't really my point, my point here again is just that full integration despite its overlooked benefits and brilliance when applied to certain things is still not necessarily the right choice for something.
The desire to move off github (and therefore any additional services besides hosting you were using, which issues are just one -- new ones keep getting added to try and cement your dependence) is something more worthwhile of thought than the idea of github turning evil. Fortunately that desire is an actual thing that's very common, or at least the desire to not be wholly dependent, and is why many people don't even use github issues to begin with even if they use github itself for hosting (or some other non-issues features). So there's not a big problem, and even if you start with using github issues, there are various migration tools to move github issues out to [alternative]. (And of course github issues have their own merits, people frequently want to switch to them! So similar migration tools exist to move from [alternative] to github issues, I wrote one for Jira years ago.)
It is brilliant to integrate things with the decentralized source control itself, you get free backups and deciding to migrate to something different in the future is easy, I think it's an overlooked approach for a lot of people. (It seems less overlooked when it comes to documentation in various forms like developer-focused .md files, or broader full static html websites which github can conveniently host for you.) Fossil is well-worth investigating for this free integration to see if it meets one's needs. But of course nothing stops you from doing it with git yourself in various ways. For personal projects, I'm pretty satisfied with being as minimal as having an issues.md file and moving things to an issues-closed.md file when I close one. I've also used the git-issue extension (https://github.com/dspinellis/git-issue -- see also its bottom section of Related Work).
But despite its brilliance it's not always the right approach. It's very easy and reasonable to want more than what is realistic for something deeply integrated with the source code itself to provide, if only for inherent conflicts of desire, let alone any question of manpower. There are very good reasons to have entirely separate (and even multiple-of-kind partially overlapping/integrating/cross-referencing) systems for source code management, issue tracking, code review, forums, IM communication, wikis, public websites, docs (of whatever kinds and types for various audiences and authors, or public or not, or team-level spikes or plannings or retrospectives)... One aspect of Fossil I found weak was its user capabilities (https://fossil-scm.org/home/doc/trunk/www/caps/ -- no custom user categories alone is a deal breaker for so many things) but flaws in the execution of a fully integrated thing isn't really my point, my point here again is just that full integration despite its overlooked benefits and brilliance when applied to certain things is still not necessarily the right choice for something.
Yes and no. It tracks the issues in the source repo. Everything is an artifact and some artifacts are bugs, technotes, etc
https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki
This is from the same person who made SQLite.
https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki
This is from the same person who made SQLite.
This has always been my #1 reservation about it. Seems like a weird degree of feature creep to me.
When Fossil didn't have those features, the frequent complaints were that Fossil doesn't have those features, and that's why they had to keep using $INERTIA_SOURCE. Now that it has those features, it's the reason not to move to it? I see. :)
All of these features cooperate and serve the same goal: coordinate the work product of people on a project, in a distributed fashion. One path to that is the nearly fully centralized model of GitHub. Another is the VCS + mailing list + bug tracker + wiki path, which requires considerable admin resources to manage, and at the end of the day is a pile of barely-cooperating services. Fossil's path is to put them all into one place so they all work properly together.
You can reference ticket IDs from a forum post.
You can point to a section of the timeline from a wiki article.
You can create diagrams in Pikchr format that live as version-controlled text in the repo and reference them from commit messages.
You can generate HTML diffs and include them into the body of a Markdown chat posting for discussion of a proposed change before committing it.
Etc., etc. It's all communication, which you need when you have multiple people working on a project, especially across time zones.
All of these features cooperate and serve the same goal: coordinate the work product of people on a project, in a distributed fashion. One path to that is the nearly fully centralized model of GitHub. Another is the VCS + mailing list + bug tracker + wiki path, which requires considerable admin resources to manage, and at the end of the day is a pile of barely-cooperating services. Fossil's path is to put them all into one place so they all work properly together.
You can reference ticket IDs from a forum post.
You can point to a section of the timeline from a wiki article.
You can create diagrams in Pikchr format that live as version-controlled text in the repo and reference them from commit messages.
You can generate HTML diffs and include them into the body of a Markdown chat posting for discussion of a proposed change before committing it.
Etc., etc. It's all communication, which you need when you have multiple people working on a project, especially across time zones.
I can't say anything to your first remark other than different people will want different things, it's unfair to level an implication of hypocrisy on the GP unless they have individually in the past actually complained about wanting to use Fossil because it lacked X but now have this complaint. Myself, I've never had a strong opinion either way, though I had only ever known Fossil for having all these extra features and thought it fascinating, not necessarily good or bad.
I did eventually try Fossil somewhat seriously for a personal project last year. I gave up and moved back to git, and don't think I'll try Fossil again, either personally or for a broader group or company project. I still find the idea of full integration interesting, just not Fossil's execution of it, not to mention some disagreements with the SCM philosophy itself. (For some it's about rebase, for me I realized I rather like the concept of staged/unstaged files or even Perforce-style pending changelists.) Meanwhile a collection of services approach actually works and cross-integrates pretty well especially when you don't have the requirement to try and self-host everything and give yourself that administrative overhead. And you'll get non-ghetto (for lack of a better descriptor) versions of those services.
Still, I don't recommend against Fossil, it's clearly good enough and aligns very well with certain values, people should evaluate it for themselves.
I did eventually try Fossil somewhat seriously for a personal project last year. I gave up and moved back to git, and don't think I'll try Fossil again, either personally or for a broader group or company project. I still find the idea of full integration interesting, just not Fossil's execution of it, not to mention some disagreements with the SCM philosophy itself. (For some it's about rebase, for me I realized I rather like the concept of staged/unstaged files or even Perforce-style pending changelists.) Meanwhile a collection of services approach actually works and cross-integrates pretty well especially when you don't have the requirement to try and self-host everything and give yourself that administrative overhead. And you'll get non-ghetto (for lack of a better descriptor) versions of those services.
Still, I don't recommend against Fossil, it's clearly good enough and aligns very well with certain values, people should evaluate it for themselves.
In my defense, I don’t ever recall a time that Fossil didn’t have all those features.
Edit: I even have receipts. Me, 11 years ago: https://news.ycombinator.com/item?id=2524574
> Am I the only one who's actively suspicious about this kind of thing? With Git, I can use whatever wiki, ticketing, documentation, and blog features I want. I don't want my VCS to be a Lotus Notes for software development.
Edit: I even have receipts. Me, 11 years ago: https://news.ycombinator.com/item?id=2524574
> Am I the only one who's actively suspicious about this kind of thing? With Git, I can use whatever wiki, ticketing, documentation, and blog features I want. I don't want my VCS to be a Lotus Notes for software development.
> all those features.
The forum, chat, and Pikchr features have been added since then. Indeed, everything in the Fossil ChangeLog has been added since then, because it cuts off a few months after your post: https://fossil-scm.org/home/doc/trunk/www/changes.wiki
The forum, chat, and Pikchr features have been added since then. Indeed, everything in the Fossil ChangeLog has been added since then, because it cuts off a few months after your post: https://fossil-scm.org/home/doc/trunk/www/changes.wiki
My criticism, over a decade ago, was that Fossil had too many features that were tangential to version control. Since then, they have added more of those tangential features. So please explain to me how my complaints in 2011 are in any way inconsistent with the state of the project today. If anything, my complaints about feature creep have been vindicated by over a decade of continued feature creep.
In 2011, I wanted the flexibility to use other wiki, ticketing, documentation, and blogging systems. In 2022, I also want the ability to use other forum and chat systems. In 2033, I will probably want the ability to choose my own text editor. I have never complained that Fossil is lacking in features, especially features that are not directly part of version control.
In 2011, I wanted the flexibility to use other wiki, ticketing, documentation, and blogging systems. In 2022, I also want the ability to use other forum and chat systems. In 2033, I will probably want the ability to choose my own text editor. I have never complained that Fossil is lacking in features, especially features that are not directly part of version control.
Fossil is ideologically opposed to rebasing which makes it (according to its own docs iirc) not so good for large teams, since the repo is full of tons of useless little commits that git users squash out before merging.
It sounds to me that people are split on whether or not SCM should include things like issues and wikis directly, or let others solve it.
Considering this is the largest point between fossil and git that I can see, maybe we should just make it so git has the capability to expose an extension API for plugging additional capabilities like this in.
Then we could probably all use git and just be happy. You could theoretically use fossil's issues and wikis with git.
Considering this is the largest point between fossil and git that I can see, maybe we should just make it so git has the capability to expose an extension API for plugging additional capabilities like this in.
Then we could probably all use git and just be happy. You could theoretically use fossil's issues and wikis with git.
Why that name “Fossil”? :-)
I can imagine someone could feel reluctant to “Fossil” only because of the name.
Also this reminds me about the Gimp – somehow not so catchy nomenclature.
I can imagine someone could feel reluctant to “Fossil” only because of the name.
Also this reminds me about the Gimp – somehow not so catchy nomenclature.
I could read it also as FOSSil with FOSS connotation (free and open-source software).
Also, a single-file repos are akin to a historical artifacts of developers work and ideas surviving through the times.
Don't we all have tons of projects sitting in their various state of abandon under the work directory? Well, Fossil lets us sweep the shame and organize these 'fossils' in a neat set of individual Fossil repo files in a grand /fossils or such directory. All repos 'readily' waiting to be respawned into a fresh work directory checkouts to perhaps offer some chance of completion.
By the way, looks like the Fossil repos can be queried directly without a check-out into a separate directory. It simplifies the review of the history and contents.
Also, a single-file repos are akin to a historical artifacts of developers work and ideas surviving through the times.
Don't we all have tons of projects sitting in their various state of abandon under the work directory? Well, Fossil lets us sweep the shame and organize these 'fossils' in a neat set of individual Fossil repo files in a grand /fossils or such directory. All repos 'readily' waiting to be respawned into a fresh work directory checkouts to perhaps offer some chance of completion.
By the way, looks like the Fossil repos can be queried directly without a check-out into a separate directory. It simplifies the review of the history and contents.
Paleontology for code!
I would love to see a better git compatible VCS. I'm not feeling good about self hosting my version control.
https://github.com/martinvonz/jj is a promising alternative which fixes many of the design mistakes of Git, but can still interact directly with Git repositories.
Funny that Google requires employees to say "THIS IS NOT A GOOGLE PROJECT, THIS IS MY 20% PROJECT", yet reserves the right to say "I can have this" at any point.
The first one is a warranty issue. The second one is a work-for-hire-copyright-law issue.
Well, Google literally paid the salary of the developer while he was developing it. This isn't even like it was something done on his personal time that Google can stake ownership in since he works there. It literally is a work product, which just happens to be not supported by Google.
This is the right approach.
Since everyone just stepped on to use git without thinking, "Because Linux uses it", we have to endure the pain of unfriendliness of git and it's already like S3 where if you want to start any competing project, it has to be git compatible to even get started.
I suppose there are SubGit, hg-git, bzr-git trying to keep their respective version control while facing git on the other end.
Somehow people miss these messages and projects like Bazaar got ran over by git for no good reason.
> We take great pride in making Bazaar easy to learn, easy to use and suitable for everyone, not just elite hackers.
> Ease of use is a core value for Bazaar and there are many places where our focus on usability shines though.
http://doc.bazaar.canonical.com/migration/en/why-switch-to-b...
I thought people were looking for tools with this philosophy.
Since everyone just stepped on to use git without thinking, "Because Linux uses it", we have to endure the pain of unfriendliness of git and it's already like S3 where if you want to start any competing project, it has to be git compatible to even get started.
I suppose there are SubGit, hg-git, bzr-git trying to keep their respective version control while facing git on the other end.
Somehow people miss these messages and projects like Bazaar got ran over by git for no good reason.
> We take great pride in making Bazaar easy to learn, easy to use and suitable for everyone, not just elite hackers.
> Ease of use is a core value for Bazaar and there are many places where our focus on usability shines though.
http://doc.bazaar.canonical.com/migration/en/why-switch-to-b...
I thought people were looking for tools with this philosophy.
I remember using git when everyone in my org was still on svn, using git-svn extension. I did not care who used it -- I just wanted lightweight branches with easy rebase/amend. Keeping all the extra checkouts, old copies and .diff files around was getting annoying.
Today, all the VCSs offer more-or-less the same set of features (Fossil being somewhat an exception in that regard). But in the past, there were quite a lot of differences. A lot of arguments for git were very technical.
Today, all the VCSs offer more-or-less the same set of features (Fossil being somewhat an exception in that regard). But in the past, there were quite a lot of differences. A lot of arguments for git were very technical.
Thanks this looks pretty cool.
Honestly all I want is a git command that runs
git commit . -m timestamp git push
I probably do something like that every 20 minutes or so.
Honestly all I want is a git command that runs
git commit . -m timestamp git push
I probably do something like that every 20 minutes or so.
Git compatibility pretty much rules out the radically different approaches that might actually be better enough to outcompete it. Like:
- Patch-based VCS (darcs, pijul)
- CRDT (live collaboration)
- Image-based systems (Smalltalk)
- Features that require the server to do stuff that Git protocol won’t do, like push notifications
In other words, I can’t imagine leaving Git unless it’s as big of an upgrade as Git was to SVN. And you can’t do that while being wire compatible.
- Patch-based VCS (darcs, pijul)
- CRDT (live collaboration)
- Image-based systems (Smalltalk)
- Features that require the server to do stuff that Git protocol won’t do, like push notifications
In other words, I can’t imagine leaving Git unless it’s as big of an upgrade as Git was to SVN. And you can’t do that while being wire compatible.
This is the premise for got. https://gameoftrees.org/
Does it have anything like lfs for large binary blobs?
[deleted]
My favourite thing about fossil is that the repo is a single SQLite database file so it’s extremely to just back it up or keep the repo in cloud storage. With Git I’ve always had problems with conflicts in the .git directory which messes things up, but fossil is a single file so it backs up to the cloud wonderfully.
That's surprising. Doesn't it seem like one big file would increase the odds of a sync conflict?
There is an extensively tested sync protocol, the whole file does not get synced each time.
https://fossil-scm.org/home/doc/trunk/www/sync.wiki
https://fossil-scm.org/home/doc/trunk/www/sync.wiki
I think the original comment was talking about a generic sync utility, not about Fossil's or Git's own protocols:
> so it’s extremely to just back it up or keep the repo in cloud storage
A single big file seems like it would cause more issues for a generic sync utility. Though I guess I can imagine sync algorithms that work better with one style vs the other.
> so it’s extremely to just back it up or keep the repo in cloud storage
A single big file seems like it would cause more issues for a generic sync utility. Though I guess I can imagine sync algorithms that work better with one style vs the other.
I'm curious how others do code review in fossil? It's something that GitHub is quite good at in my opinion; raising pull requests, having pre-merge checks, commenting on individual lines of changes, etc etc is all useful. It's something I can't see how to do in fossil.
Note that you can get free online fossil hosting at https://chiselapp.com/ .
I am not sold on the wiki and issue tracker. What would be a killer feature is a web UI interface to fossil commands like sublime merge for git.
One thing that has prevented me from trying out fossil is there is no squash. The team has a principled stand on not having it.
Github fills the gab between fossil and git and I don't need to host it myself.
The author of Fossil considers rebase harmful, and because of that, it wasn't implemented[1].
I'm not a fan of that decision. I don't want to live with my mistakes forever, especially on local branches.
[1] - https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md
I'm not a fan of that decision. I don't want to live with my mistakes forever, especially on local branches.
[1] - https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md
Rebase is may favourite part of git. Committing a small bug fix as you go and then plucking it out and moving it to the front of the queue is just so handy and avoids all those "Implement feature X, and a few bug fixes too, lol" commits.
Not to mention a stream of WIP commits that mean at any point I can diff the mess I've made in my editor to when it was last working (or any other time). Often that's enough to reveal the problem. If you don't commit often enough, you can't do that, but if you can't rebase, the history is full of junk that should be collapsed before going public.
Not to mention a stream of WIP commits that mean at any point I can diff the mess I've made in my editor to when it was last working (or any other time). Often that's enough to reveal the problem. If you don't commit often enough, you can't do that, but if you can't rebase, the history is full of junk that should be collapsed before going public.
Yeah interactive rebasing is such a fundamental part of how I work with git, that's a total deal breaker. It's how you both "commit early and often" and leave a logical chain of commits behind in the end.
Without the ability to rewrite local history, you're either not commiting often (risky) or leaving long streams of poorly documented "work-in-progress" commits in the main project history.
Without the ability to rewrite local history, you're either not commiting often (risky) or leaving long streams of poorly documented "work-in-progress" commits in the main project history.
If I undestand it correctly, Fossil does not support a reordering of commits. However, some of rebase effects could be achieved by using so called private branches (these do not get pushed to remote). The desired sequence could be created by cherrypicking between private branches, then the result merged onto the trunk or whatever normal branch and pushed to remote.
For simple squash of WIP, the private branch works quite naturally, and simply merges onto the normal branch. For more involved reordering, it would be too cumbersome to be practical.
However, Fossil philosophy advocates a factual approach to commit history, unlike a 'maintained' approach that's so widely expected by Git-based workflows, and which calls for the use of rebase.
For simple squash of WIP, the private branch works quite naturally, and simply merges onto the normal branch. For more involved reordering, it would be too cumbersome to be practical.
However, Fossil philosophy advocates a factual approach to commit history, unlike a 'maintained' approach that's so widely expected by Git-based workflows, and which calls for the use of rebase.
Does it have something like git amend for local branches? That will at least allow the latest commit to be changed.
In case anyone is confused, git amend can amend the changes, not just the commit message. I didn't notice this for a while, and finally got around to reading about how it works. https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
In case anyone is confused, git amend can amend the changes, not just the commit message. I didn't notice this for a while, and finally got around to reading about how it works. https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
Fossil's amend command covers a wide set of commit attributes. This can be applied not only to the latest commit, but also at any historical point. Looks like it's implemented as a new special commit with some internal logic which overrides the original commit's metadata. This is actually done without altering the historical record of the original commit; it's transparent on the log/timeline, but the amend event entry can also be made visible.
Very clever way of letting user fix some attribution mistakes/typos, yet not mangle the original commit.
However, for amending the actual file changes, like it could be done with git --amend, Fossil requires another proper commit; for historical amends, the new commit has to be put onto a new branch.
Fossil-scm website has a detailed help section for all commands, including the amend.
Very clever way of letting user fix some attribution mistakes/typos, yet not mangle the original commit.
However, for amending the actual file changes, like it could be done with git --amend, Fossil requires another proper commit; for historical amends, the new commit has to be put onto a new branch.
Fossil-scm website has a detailed help section for all commands, including the amend.
Fossil has private branches which can serve the same purpose. When you merge a private branch it looks just a single commit, similar to a squashed merge.
That throws out the baby with the bathwater. I frequently merge feature branches with changes still split into a small number of commits, each representing an atomic step associated with the overall change.
That's not true. In fossil when you have multiple cherry-picks in a single merge, you can still get the hashes directly.
https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#...
https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#...
[deleted](1)
Merges should be considered harmful and disabled by default.
They ruin history, get in the way of bisect, may not be reproducible, etc, etc.
Sometimes they may be used but more likely as a superuser operation
They ruin history, get in the way of bisect, may not be reproducible, etc, etc.
Sometimes they may be used but more likely as a superuser operation
GitHub's button to update the current branch annoys me. It creates a merge commit back from the main branch to the feature branch. I would rather it back up the current branch and rebase it or something, or just let me do it the right way manually (rebase and force push).
You can set on the repository if you want it to rebase instead[0]
[0]: https://docs.github.com/en/pull-requests/collaborating-with-...
[0]: https://docs.github.com/en/pull-requests/collaborating-with-...
Annoyingly this always re-writes commits (i.e. never fast-forwards), which means that if you have branches based on the branch you're merging they will need to be rebased, and git will complain about deleting the branch because it looks like it's unmerged.
I know about that but don't know if it works for updating a branch before merging it. I'll have to try changing it to that setting.
I've never had an issue with merges in 10 years of using git.
Do everything but everything mediocre.
Is fossil just a "me too" of git? The release date is suspiciously shortly after git.
It came out two years after Git and Mercurial. Richard Hipp cites Monotone (which preceded both) as an early influence, and says he evaluated Git, Mercurial, and Monotone before deciding to implement his own DVCS on top of SQLite in order to develop SQLite.
https://fossil-scm.org/home/doc/trunk/www/history.md
https://fossil-scm.org/home/doc/trunk/www/history.md
It has explicitly different design goals than git. Read its comparison page of fossil vs. git features.
Git is just a "me too" of the BitKeeper source control system that Linus used before he wrote git. Linus isn't even trying to hide the fact--he explicitly says he wrote git because he had to move off BitKeeper after a license conflict and he needed something that was functionally similar for kernel development.
Git is just a "me too" of the BitKeeper source control system that Linus used before he wrote git. Linus isn't even trying to hide the fact--he explicitly says he wrote git because he had to move off BitKeeper after a license conflict and he needed something that was functionally similar for kernel development.
I don't like the monoculture either, but at this point some knowledge of git is an essential skill. In fact pretty much the only chance you have of avoiding git would be to build your own stuff on something else, hire/collaborate only with others who share the same view, and never interact with basically any other open source.
So given some git knowledge is necessary anyway, there are alternatives interfaces to git that solve the simplicity problem, and any other tool is going to have friction (small ecosystem, few integrations, smaller community), why use something else? (I mean this genuinely)
I just don't see the dominance of git changing for the next decade, especially if there's no answer to my first question (for whatever aims to replace it). It's not even like there's git lock-in: it could be replaced, just like SVN was. It's just it doesn't seem like there's compelling reason to, and thus no desire.