That old post, by Keith Packard: https://keithp.com/blogs/Repository_Formats_Matter/
I've read through the documentation on the Fossil file format: https://www.fossil-scm.org/index.html/doc/trunk/www/fileform...
Maybe I'm just being dense, but e.g. in the case of the wiki which Fossil advertises as a core feature over Git, it's not clear to me how it wouldn't be implementable in a similar way in Git by some convention of creating commit objects & having some web UI that understands that convention, and if so the real differentiation is just in the porcelain part of the UI.
Not a complete answer, but I like to think about it this way:
git was made by a file-system expert and is file-system based and Fossil was made by a database expert and is SQLite based. So a lot of the limits can probably derived from the limits of and differences between old school file systems and traditional relational databases.
I wrote old school and traditional because when is comes to modern file-systems and modern databases the lines get blurry.
Fossil has a GUI built-in that makes visualizing the repo easy. There are tools for Git that provide similar functionality.
1. "Git makes it difficult to find successors (descendents) of a check-in" - Use a Git GUI like SourceTree and it's really damn easy to jump to a commit and review the entire graph up and down using links to jump to parent/child commits (even multiple parents for merges.
2. "The mental model for Git is needlessly complex" - Again, a Git GUI can make it really easy to keep track of "changed but not ready to commit, changed and ready to commit, local and remote branch"
3. "Git does not track historical branch names" - The example he provides here shows a visual graph in Fossil of the branch history. The exact same thing is available in Git via "git log --graph --all --decorate" or a GUI that shows the graph.
4. "Git requires more administrative support" - "apt install git" or "brew install git" or most systems come with it pre-installed. Windows is a bit more annoying.
5. "Git provides a poor user experience" - "Just memorize the shell commands". Again, there is tooling available for Git to remove this requirement.
It seems to me that his main complaint is that Git doesn't provide a GUI out of the box to make visualizing the repository easier. I get that, but there are enough tooling options available that it becomes a non-issue. SourceTree is a native app for Mac and Windows and there are various other GUIs even CLI GUIs for Git that users have a lot of flexibility. Fossil would seem to require them to use the GUI provided by Fossil whether they like it or not.
I'm not bashing on Fossil at all. I'm just saying that his arguments here show a lack of knowledge about the available tooling for Git and not fundamental advantages of Fossil over Git.
No, that Git command only shows current local and remote branch heads, not the branches to which a commit historically belonged. If you look at the link he posted, that git hub page provides that same info. AFAIK Git does not store this historical information. If you look at the example links he provides, in Fossil each commit has tags saying what branch(es?) it belonged to.
I do agree with the rest of your points. I use a combo of GUI for viewing current state and easily adding/removing file, I also use more complicated git commands when I need to do stuff that isn't easy in the GUI I use.
It quickly fails to scale. The issue is when you want to use commands to find the successors and build some processing over it..
>"The mental model for Git is needlessly complex" - Again, a Git GUI can make it really easy to keep track of "changed but not ready to commit..
That is a very limited situtation. In the course of using a VCS, for a long running project, one encounters numerous situtations where having a complex mental modal quickly feels exhausting...
> The exact same thing is available in Git via "git log --graph --all --decorate" or a GUI that shows the graph.
No. it is a bit different. In Git, branches can easily jump around, and the commits that were previously under a branch will have no information in them regarding which branch they were originally made..
>. Again, there is tooling available for Git to remove this requirement.
Again, you are not thinking like a power user. GUI's only works if you follow some predefined "happy path"..
> I'm just saying that his arguments here show a lack of knowledge about the available tooling for Git
To me, it seems that you are lacking enough experience to identify what the author is talking about..
I have not yet found such a simple description for any other DVCS, although I admit that given that Git is everywhere nowadays has not motivated my to do much research.
In the particular case of Fossil, if I read https://fossil-scm.org/index.html/doc/trunk/www/concepts.wik... (which is supposed to explain the concepts), it already begins explaining workflows, specifying that I have to choose between two alternatives, for which I do not even have a complete explanation (what happens if I divert from the suggested workflow?). Now that is what I call complex!
I guess what I'm getting at is that even if Fossil is better than Git, the problems it's solving don't seem to be particularly urgent to solve. Less complexity is good, but it would need to be considerably more elegant than Git to make me not want to use a VCS that's basically standard now.
I don't see anything in the FAQ, overview, or questions page where I'm thinking "Oh, this is something I couldn't do in basic Git." For a large organization I can see the benefits of simplifying, but as a developer I feel like I'm missing the hook.
Off the top of my head, Git improvements that I regularly do want:
- Large file support and binary file support. LFS exists, but is clunky and annoying to work with.
- Pushing/pulling directly to someone else's local repository (ie, if a remote goes down). This is always harder to do than I expect.
- Better octopus merging; once commits in git have multiple parents, there are sometimes unexpected complications that can arise in future merges.
Does Fossil solve any of those problems?
I use org mode files for my issues and wiki-like features for my projects, and it works because my projects are very-small scaled. But having to commit issues and merge them can get boring very quickly. I haven't tried fossil, but if it has a nice quick UI for that, I might be interested.
WRT local push/pull, I don't have any problems with it in Mercurial (altho it's sth. I don't do often). What happens with git? WRT other problems, well, those are problems of all DVCSes and VCSes, so it's a bit too harsh to judge fossil by them, no?
Git command line is not inelegant, it's confusing, even at the basic level. An improvement on that is not only aesthetic. Magit is popular for a reason.
Maybe I'm just blind. Does anyone have a link or would they be willing to do a writeup on what fundamentally makes Fossil better than Git (ie. not just from a user interface point of view)?
> Git command line is not inelegant, it's confusing
Agreed, but it's not unusably bad. The question isn't whether or not Fossil can do better than Git's command line, it's whether it can do so much better that it's worth learning a new set of abstractions.
For new developers or large organizations, I can see it. But if I'm used to Git, and I can handle the bad command-line interface, why should I switch then?
Keep in mind that I'll still want to use Magit anyway, because the improvement of Magit is in no small part its Emacs integration. It kind of strikes me as a losing battle to ever market a VCS based on a GUI. When are you ever going to want to use a VCS without integrating it into your IDE? Even if Git's command-line interface was amazing, I would still want to be able to overlay `git-blame` directly onto my source.
As per the JSON API and TH scripting, they're both for the web UI (AFAIK) which I was trying to avoid if possible as it slowed down my overall workflow (though much more time has been put into making that usable by the fossil devs). As a last note TH is a bit of an oddity which I imagine may be a turn-off to other people getting started with tweaking fossil.
I'm curious why do you do the octopus merges often. I'd probably avoid them as much as possible, mainly because small incremental changes verified by CI/CD are easier to deal with than multiple things at once. What's the benefit of merging more than one thing?
Off the top of my head:
- I was working in a large organization, and building a prototype of a feature that another team wanted to start consuming on their dev branch before it was merged into stable. We could have rebased all of their changes onto a new branch off of mine, but I thought, "meh, why not try to give their branch two parents just to see what happens." Long story short, I will not do something like that again.
- I sometimes work on Open Source code with protected branches. Once the code is merged into stable, it's all MIT licensed. Before it's merged into stable, it's not. One time I had the deceptively bright idea, "hey, why can't stable merge from two branches; one that contains license information and one that contains code?"
It's all fairly rare edge case stuff that's avoidable with a little bit of discipline and practice, but especially if I'm working with a large number of feature teams, I will sometimes notice that I'm relying on cherry-picking and rebasing not because it makes more sense than an octopus merge, but because it's just generally less dangerous to do.
Cherry-picking has its own set of problems, because when Git does conflict resolution, it cares about commit order. This means that cherry-picked commits can sometimes overwrite later changes from the source branch after they've been merged.
These are problems that I don't know how to solve, so I just avoid them. But if a VCS did solve them, I would be tempted to switch.
This can be done by specifying the URL that points to their repository's .git directory in the git push or fetch command (instead of origin). IIRC, the only complication is if you try to push a branch that's currently checked out on the remote.
sudo apt-get install fossil
fossil init test
fossil open test
Is it a matter of taste that the above sentence is well constructed or not?
I think that would be a good way to drive adoption.
And HN discussion (with over 600 comments) here: https://news.ycombinator.com/item?id=16806114
Well... the tickets are things that live in the repository like a commit, so can reference other entries, and are referenceable by other entries, in a first class way. So “just porcelain“ or a “simple matter of programming” for git, in the dismissive sense.
Well... the tickets are things that live in the repository like a commit, so can reference other entries, and are referenceable by other entries, in a first class way, so it’s a “simple matter of programming” for git in the dismissive sense.
Don't get me wrong, I do agree fossil is adding some new cards to the table. I just think it would be better implemented as extensions to git than a new system made from scratch.
For anyone who wants to see what's possible using low level git tools: https://github.com/google/git-appraise