Fossil is neat because of the ‘total package’ it provides: autonomous ticketing, wiki, etc. like the title says. The problem is that Git is now the standard for version control. I would love for Fossil to evolve into a streamlined, batteries-included Git porcelain. I know that for all Fossil’s advantages, there is no way I am going to convince anyone to use it over Git for the foreseeable future.
I know that for all Fossil’s advantages, there is no way I am going to convince anyone to use it over Git for the foreseeable future.
I don’t think so either, but it seems like something one can at least use for personal projects for people to notice it more. I’m currently considering moving a few of my smaller projects to fossil, but that might take a while.
Who offers Fossil hosting (i.e. Github for Fossil)? Chisel and Sourceforge are the only ones I was able to find.
One of git’s killer features for me is that there are many low-cost hosting options, so I can easily backup my projects outside of my local machine. Sure Fossil makes it easy to run your own remote server, but that’s one more thing I have to secure & maintain.
Those are the only two I know of too. I guess there’s little interest by design, but perhaps I would have said the same about hosting a .git directory on a HTTP server 10 years ago.
One of git’s killer features for me is that there are many low-cost hosting options
Do you really think so? I’m not sure that people say “I’d really like to use [non-git-CVS], but where am I going to host it at a cheap price”. Git’s killer feature is that it is git, like all industry standards, the main reason one is interested in them, is that they are widely used – which is in itself not good or bad (think of Email).
Anything with ssh access?
fossil push ssh://
or simply scp/rsync/rclone repository - it’s just a single file.
I host my repos on an orange pi and backup them on b2 with rclone.
I’m confused. One of Fossil’s selling points is an integrated bug tracker, but scanning through the recent fossil development history, most of the links to bugs fixed refer to their forum, not their bug tracker. I was trying to see how the bug tracker integrates into the VCS, but I haven’t found a single commit which links to the bug tracker yet.
I’m not sure if I’m misunderstanding you point, but I my understanding of “integrated/built-in bug tracker” is that the tickets, forum posts, wiki are all cloned with the “VCS”, and synchronized together. So I type
fossil sync
in a local checkout, then open the web ui with
fossil ui
and can create tickets, comment on forum posts and edit wiki articles, even while I’m offline. I haven’t found out what the linking abilities are between commits and tickets (I’d have to try if the wiki syntax can be used), but that might be what you’re looking for.
People using git and svn often go to great lengths to integrate various third-party issue trackers with their version control, so that they can:
look at a commit and follow a link to the issue it fixes
look at an issue and see all the commits which relate to it
I just assumed that given that the VCS and issue tracker come bundled together, linking issues and commits would be a “first class citizen”, and would be widely used. I was therefore surprised to not see much evidence of its use. I have now managed to find an example.
Unfortunately, the comparison is written in such a clearly biased way that it probably makes fossil sound worse than it is (I mean you wouldn’t need to resort to weasel words and name-calling if fossil was valid alternative whose benefits spoke for themselves .. right?). Why would anyone write like that if their aim is to actually promote fossil?
The table at the top is distractingly polemic, but the actual body of the essay is reasonable and considers both social and technical factors.
My guess is that author is expecting the audience to nod along with the table before clicking through to the prose; it seems unlikely to be effective for anyone who doesn’t already believe the claims made in the table.
Not sure using a biased comparison from the tool author is useful. Even then, the least they could do is use factual language.
This is always something that gripes me reading the recurring fossil evangelism: git criticism is interesting and having a different view should give perspective, but the fossil author always use this kind of language that makes it useless. Git adapts to many kind of teams and workflow. The only thing I take from his comparison is that he never learnt to use it and does not want to.
Now this is also a very valid criticism of git: it is not just a turn-key solution, it needs polish and another system needs to put forth a specific work organization with it. That’s a choice for the project team to make. Fossil wants to impose its own method, which of course gives a more architected, polished, finish, but makes it impossible to use in many teams and projects.
One of the main reasons for me for not using Fossil is point 2.7 on that list: “What you should have done vs. What you actually did”. Fossil doesn’t really support history rewrites, so no “rebase” which I use nearly daily.
This is also a problem with Git. Like you, I use rebase daily to rewrite history, when that was never really my objective; I just want to present a palatable change log before my changes are merged. Whatever happens before that shouldn’t require something as dangerous as a rebase (and force push).
I don’t think it makes any sense to describe rebases as ‘dangerous’, nor to say that you want to present a palatable change log without rewriting history unless you’re saying you want the VCS to help you write nicer history in the first place?
Rebase is not dangerous. You have the reflog to get back to any past state if needed, you can rewrite as much as you need without losing anything.
Now, I see only two ways of presenting a palatable change log: either you are able to write it perfectly the first time, or you are able to correct it. I don’t see how any VCS would allow you to do the first one. If you use a machine to try to present it properly (like it seems fossil strives to do), you will undoubtedly hit limitations, forcing the dev to compose with those limitations to write something readable and meaningful to the rest of the team. I very much prefer direct control into what I want to communicate.
I think whether rebase is dangerous depends on the interface you are using Git with. The best UI for Git is, in my opinion, Magit. And when doing a commit you can choose from a variety of options, one of them being “Instant Fixup”.
I often use this when I discover that I missed to check-in a new file with a commit or something like that. It basically adds a commit, does an interactive rebase, reorders the commits so that the fixup-commit is next to the one being fixed and executes the rebase pipeline.
There are other similar options for committing and Magit makes this straight-forward. So much, indeed, that I have to look up how to do it manually when using the Git CLI.
I prefer to work offline. Prior to Git I used SVK as frontend for SVN since it allowed offline use. However, once Git was released I quickly jumped ship because of its benefits, i.e. real offline copy of all data, better functionality (for me).
In your linked document it states “Never use rebase on public branches” and goes on to list how to use rebase locally. So, yes, using rebase on public branches and force-pushing them is obviously only a last resort when things went wrong (e.g. inadvertently added secrets).
Since I work offline, often piling up many commits before pushing them to a repo on the web, I use rebase in cases when unpushed commits need further changes. In my other comment I mentioned as example forgotten files. It doesn’t really make sense to add another commit “Oops, forgotten to add file…” when I just as easily can fixup the wrong commit.
So the main reason for using rebase for me is correcting unpushed commits which I can often do because I prefer to work offline, pushing the latest commits only when necessary.
In addition to what @gettalong said, keep in mind the original use-case of git is to make submitting patches on mailing lists easier. When creating a patch series, it’s very common to receive feedback and need to make changes. The only way to do that is to rebase.
Git has readonly web interface: https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb
Also there is git-bug: https://github.com/MichaelMure/git-bug
Git bug is actually amazing. At first I thought it was just a wrapper around GitHub/GitLab issues, but it actually tracks bugs in the git repo itself!
This is really cool. Thanks for the endorsement, I’ll have to give it a try.
cgit is also available: https://git.zx2c4.com/cgit/
And there’s also stagit, for a totally static interface.
Thank you! I hadn’t seen that.
Fossil is neat because of the ‘total package’ it provides: autonomous ticketing, wiki, etc. like the title says. The problem is that Git is now the standard for version control. I would love for Fossil to evolve into a streamlined, batteries-included Git porcelain. I know that for all Fossil’s advantages, there is no way I am going to convince anyone to use it over Git for the foreseeable future.
There’s some brainstorming on that idea here: https://www.fossil-scm.org/xfer/wiki?name=Fossil-NG
I don’t think so either, but it seems like something one can at least use for personal projects for people to notice it more. I’m currently considering moving a few of my smaller projects to fossil, but that might take a while.
Who offers Fossil hosting (i.e. Github for Fossil)? Chisel and Sourceforge are the only ones I was able to find.
One of git’s killer features for me is that there are many low-cost hosting options, so I can easily backup my projects outside of my local machine. Sure Fossil makes it easy to run your own remote server, but that’s one more thing I have to secure & maintain.
Those are the only two I know of too. I guess there’s little interest by design, but perhaps I would have said the same about hosting a .git directory on a HTTP server 10 years ago.
Do you really think so? I’m not sure that people say “I’d really like to use [non-git-CVS], but where am I going to host it at a cheap price”. Git’s killer feature is that it is git, like all industry standards, the main reason one is interested in them, is that they are widely used – which is in itself not good or bad (think of Email).
Anything with ssh access? fossil push ssh:// or simply scp/rsync/rclone repository - it’s just a single file. I host my repos on an orange pi and backup them on b2 with rclone.
I wonder if Google Drive / OneDrive / Dropbox would work. I’m skeptical because SQLite often has problems with these.
I’m confused. One of Fossil’s selling points is an integrated bug tracker, but scanning through the recent fossil development history, most of the links to bugs fixed refer to their forum, not their bug tracker. I was trying to see how the bug tracker integrates into the VCS, but I haven’t found a single commit which links to the bug tracker yet.
I’m not sure if I’m misunderstanding you point, but I my understanding of “integrated/built-in bug tracker” is that the tickets, forum posts, wiki are all cloned with the “VCS”, and synchronized together. So I type
in a local checkout, then open the web ui with
and can create tickets, comment on forum posts and edit wiki articles, even while I’m offline. I haven’t found out what the linking abilities are between commits and tickets (I’d have to try if the wiki syntax can be used), but that might be what you’re looking for.
People using git and svn often go to great lengths to integrate various third-party issue trackers with their version control, so that they can:
I just assumed that given that the VCS and issue tracker come bundled together, linking issues and commits would be a “first class citizen”, and would be widely used. I was therefore surprised to not see much evidence of its use. I have now managed to find an example.
Fossil is really an excellent system, and I encourage people to use it. I’ve been very happy using it for a variety of purposes.
There is a comparison of git and fossil there, https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki
Unfortunately, the comparison is written in such a clearly biased way that it probably makes fossil sound worse than it is (I mean you wouldn’t need to resort to weasel words and name-calling if fossil was valid alternative whose benefits spoke for themselves .. right?). Why would anyone write like that if their aim is to actually promote fossil?
The table at the top is distractingly polemic, but the actual body of the essay is reasonable and considers both social and technical factors.
My guess is that author is expecting the audience to nod along with the table before clicking through to the prose; it seems unlikely to be effective for anyone who doesn’t already believe the claims made in the table.
This is what’s turned me off from even considering using it.
“Sprawling, incoherent, and inefficient”
Not sure using a biased comparison from the tool author is useful. Even then, the least they could do is use factual language.
This is always something that gripes me reading the recurring fossil evangelism: git criticism is interesting and having a different view should give perspective, but the fossil author always use this kind of language that makes it useless. Git adapts to many kind of teams and workflow. The only thing I take from his comparison is that he never learnt to use it and does not want to.
Now this is also a very valid criticism of git: it is not just a turn-key solution, it needs polish and another system needs to put forth a specific work organization with it. That’s a choice for the project team to make. Fossil wants to impose its own method, which of course gives a more architected, polished, finish, but makes it impossible to use in many teams and projects.
Maybe they don’t care about widely promoting fossil and just created that page so people stop asking about a comparison?
One of the main reasons for me for not using Fossil is point 2.7 on that list: “What you should have done vs. What you actually did”. Fossil doesn’t really support history rewrites, so no “rebase” which I use nearly daily.
This is also a problem with Git. Like you, I use rebase daily to rewrite history, when that was never really my objective; I just want to present a palatable change log before my changes are merged. Whatever happens before that shouldn’t require something as dangerous as a rebase (and force push).
I don’t think it makes any sense to describe rebases as ‘dangerous’, nor to say that you want to present a palatable change log without rewriting history unless you’re saying you want the VCS to help you write nicer history in the first place?
Rebase is not dangerous. You have the reflog to get back to any past state if needed, you can rewrite as much as you need without losing anything.
Now, I see only two ways of presenting a palatable change log: either you are able to write it perfectly the first time, or you are able to correct it. I don’t see how any VCS would allow you to do the first one. If you use a machine to try to present it properly (like it seems fossil strives to do), you will undoubtedly hit limitations, forcing the dev to compose with those limitations to write something readable and meaningful to the rest of the team. I very much prefer direct control into what I want to communicate.
I think whether rebase is dangerous depends on the interface you are using Git with. The best UI for Git is, in my opinion, Magit. And when doing a commit you can choose from a variety of options, one of them being “Instant Fixup”.
I often use this when I discover that I missed to check-in a new file with a commit or something like that. It basically adds a commit, does an interactive rebase, reorders the commits so that the fixup-commit is next to the one being fixed and executes the rebase pipeline.
There are other similar options for committing and Magit makes this straight-forward. So much, indeed, that I have to look up how to do it manually when using the Git CLI.
Why do you need to rebase? https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing
I prefer to work offline. Prior to Git I used SVK as frontend for SVN since it allowed offline use. However, once Git was released I quickly jumped ship because of its benefits, i.e. real offline copy of all data, better functionality (for me).
In your linked document it states “Never use rebase on public branches” and goes on to list how to use rebase locally. So, yes, using rebase on public branches and force-pushing them is obviously only a last resort when things went wrong (e.g. inadvertently added secrets).
Since I work offline, often piling up many commits before pushing them to a repo on the web, I use rebase in cases when unpushed commits need further changes. In my other comment I mentioned as example forgotten files. It doesn’t really make sense to add another commit “Oops, forgotten to add file…” when I just as easily can fixup the wrong commit.
So the main reason for using rebase for me is correcting unpushed commits which I can often do because I prefer to work offline, pushing the latest commits only when necessary.
In addition to what @gettalong said, keep in mind the original use-case of git is to make submitting patches on mailing lists easier. When creating a patch series, it’s very common to receive feedback and need to make changes. The only way to do that is to rebase.