I am always doubtful when people say that accessing information inside git is hard. I totally agree that defaults in git can be improved (and they are, git restore and git switch are a much better alternative to git checkout that I no longer use). So let’s review the section “A Few Reasons Why SQLite Does Not Use Git”:
Make it an alias if you use it often. Alias is what helps you create your own good default (until everyone uses the same alias and in that case it should be part of the base set of commands).
“Git makes it difficult to find successors (descendants) of a check-in”
Likewise you could consider making it an alias if you use it often. Aliases can also be used as a post-it to help you remember what are the command that you find useful but you only use once in a blue moon!
The mental model for Git is needlessly complex
I may agree about that one. For reference, this is what the article says:
A user of Git needs to keep all of the following in mind:
The working directory
The "index" or staging area
The local head
The local copy of the remote head
The actual remote head
If git fetch was run automatically every so often, as well as git push (of course in a personal branch), then this model could be simplified as
the working directory
the “index” or staging area (I actually think that being able to have more than one for drafting multiples commit at once, like a fix and a feature at the same time would be better than only having a single index)
your working copy of the shared branch
the shared branch
And integrating your changes (merging/rebasing) should probably be exclusively done using a PR-like mechanism.
Git does not track historical branch names
I’m skeptical about the usefulness of this. But since git was my first real vcs (10 years ago), it may just be that I have not used a workflow that took advantaged of persistant branches. I assume that git annotate could be a solution here.
Git requires more administrative support
most developers use a third-party service such as GitHub or GitLab, and thus introduce additional dependencies.
That’s absolutely true but I’m not sure it’s a real issue. Given how many strategies there are for CI/CD (and none is the definitive winner yet) I do think that being able to select the right option for you/your team/your org is probably a good idea.
I highly disagree about that xkcd comics. Git is compatible will all workflows so you have to use a subset of all the commands. Of course you will have more commands that you never use if a software is usable for all the workflow that you don’t use. But you need about 15 commands to do stuff, 30 to be fluent, and some more to be able to help anyone. Compared to any other complex software that I use I really don’t think that it’s an unreasonably high count. That being said I totally agree that git from 10+ years ago was more complex and we should correctly teach what is needed to junior. HTML/css/js is a nightmare of complexity but it doesn’t stop 15 years old kid with no mentoring to build cool stuff because you don’t need to know everything to be able to do most of the things you may think of, just a good minimal set of tools. And people should definitively take the time to learn git, and stop using outdated guide. Anything that don’t use git switch, git restore and git rebase --interactive and presents you have to inspect the history in length (git log --graph or any graphical interface that show the history in a graph, git show, and more generally than you can filter the history in any way you want, being by author, date, folder, file type, …) is definitively not a good guide.
To sum-up, I think that from this presentation fossil seems more opinionated than git which means that it will be simpler as long as your workflow exactly matches the expected workflow whereas using git requires to curate its list of commands to select only the one useful for yours.
Thanks for this write-up!
It seems that you've kinda confirmed the points made by the Fossil team by showing that while all of their pain points are addressable, addressing those pain points takes more knowledge and experience compared to Fossil's implemented solutions. Opinionated workflows are best presented up front for beginners. It's no surprise that people with experience and have developed their own workflows already wouldn't value this highly unless they are often charged with helping beginners learn a git workflow.
git switch
Oh wow, I didn't know about this one. I guess it's relatively new?
Is it just a convenience command to try and be more specific (less multi purpose) than git checkout for switching branches or does it bring any extra benefit? ...I'm already quite used to my git co alias, to the point that it's almost hardwired to my fingers by now :P
Yes git restore and git switch were made specifically to be simplified, more specific commands which are safe from performing destructive actions without warning. They were implemented in Git 2.23.0 in 2019.
2019, so 4-5 years ago so not that recent but not ancient either. But unfortunately tutorials have not been updated.
I would say that the biggest benefit of git switch is that you can't switch to a detached state without using a flag (--detached or -d). If you do git co $tag or git co $sha-1 you may get at one point the error “you are in a detached state” which is ununderstable for begginers. To get the same error with git switch you must explicitely use git switch --detached $tag/$sha-1 which makes it much easier to understand and remember that you are going to do something unusual.
More generally it's harder to misuse git switch/git restore. And it's easier to explain them since the only do one thing (unlike git checkout which is a mess !).
So if it's only for you git checkout is fine, but I would still advice to use git switch and git restore so you will have an easier time to teach/help begginers.
I am in a perpetual wonderland of git confusion, but this was a good read. And maybe I now have a pathway to enlightenment.
If you try to learn git one command at a time on the fly, git is HARD. If you take the time to understand its internal data structure it's much, much easier to learn. Unfortunalely most people try to do the former because it works well (or better) for most tasks.
Thanks. I guess it's the perpetual problem of learning something new. Instead of starting at the beginning, we trick ourselves into thinking that we can skip the fundamentals. Then we have difficulty and think that the problem is one of complexity or just over our heads instead of our approach.
In fairness, sometimes it is useful to get hands on experience with a system before you dig into its fundamentals so that you have a reference point that helps you absorb the information.
https://learngitbranching.js.org
Is a very accessible browser game that I found useful on my Git journey to start to grasp the underlying structures and operations such as rebase.
Thanks
I use Fossil for all of my personal projects. Having a wiki and bug tracker built-in is really nice, and I like the way repositories sync. It's perfect for small teams that want everything, but don't want to rely on a host like GitHub or set up complicated software themselves.
There are still no built-in CI/CD, artifacts repository and AI assistant? Awful!
::: spoiler spoiler
sarcasm
:::
Ooh awesome. The more alternatives to git the better. I'm still bitter over Bitbucket dropping hg support. Suppose with this there's no need for a bitbucket.
Having the core of the repo being a sqlite DB is neat. Certainly seems better than needing external tools like I saw posted a couple days ago to do the same sort of queries. Of course literally any vcs is going to have better CLI UX than git, so not sure how much credit I can give fossil there.
I checked out fossil once and looks like it doesn’t have an equivalent to Pull Request so I moved on. It wasn’t clear how anyone could begin to be a contributor to a project if I host on fossil.
PRs are a feature introduced by GitHub. I guess Fossil bundles would be close enough to them.
EDIT: I was wrong. Turns out Git does have a pull request feature. It requires you to upload your code to a public repository, after which it generates a message asking to pull, which can then be sent via any medium to the repository owner. It doesn’t require patches, or GitHub. Differences to note: these aren’t like GitHub/Gitlab/Gitea pull requests, where you’re given a simple web interface and have to merge from a repository on that instance. Your repository can be hosted anywhere using git request-pull. You’ll most likely then send the request through email, and get feedback in the form of replies. If you push newer changes to that branch, you’ll have to request another pull, as request-pull only specifies a commit range. But yeah, I guess got technically does have pull requests. (For the scope of OP’s question however, I don’t believe he meant this.)
This is objectively wrong! Git has 'request-pull' command that generates a message to an upstream maintainer to pull changes from an online downstream clone. That request message can be sent by email or some other means. But no patches are involved. And no - Github did not invent it. It was there before Github existed. In fact, there is a rant by Torvalds as to how GitHub reimplemented PRs poorly, throwing away good features of the request-pull command.
Thank you for that information. I had no idea that command existed, I guess because primarily I’ve seen people sending patches over email. I’ve updated my original comment with additional information. Thanks for calling me out 😅
I didn't see the diff command last time, thanks for that. It still feels like a miss for fossil to host a web view and forum but not a pull request-like section.
Patches have terrible UX. IMO, if projects don't support the equivalent of pull or merge requests, they are just turning away contributors.
...ew.
One of the strengths of open source is its diversity of technical solutions. It's a feature, not a bug.
Before git, there were other open source version control systems, and they still work. For example, sometimes a centralized repository is the right tool for the job, and subversion is still there.
Fossil is cool. Almost no one uses it, aside from sqlite themselves, so it sort of feels like a roll-your-own VCS. But it works for them, and I suspect it would work for a lot of other people too.
sqlite has some interesting philosophical foundations, and that makes it an unique project. :)
@mac Related: Why the SQLite team uses Fossil instead of Git https://sqlite.org/whynotgit.html
I am always doubtful when people say that accessing information inside git is hard. I totally agree that defaults in git can be improved (and they are,
git restoreandgit switchare a much better alternative togit checkoutthat I no longer use). So let’s review the section “A Few Reasons Why SQLite Does Not Use Git”:git log --graph --oneline --author-date-order --since=1weekMake it an alias if you use it often. Alias is what helps you create your own good default (until everyone uses the same alias and in that case it should be part of the base set of commands).
git log --graph --oneline --all --ancestry-path ${commit}~..Likewise you could consider making it an alias if you use it often. Aliases can also be used as a post-it to help you remember what are the command that you find useful but you only use once in a blue moon!
I may agree about that one. For reference, this is what the article says:
If
git fetchwas run automatically every so often, as well asgit push(of course in a personal branch), then this model could be simplified asAnd integrating your changes (merging/rebasing) should probably be exclusively done using a PR-like mechanism.
I’m skeptical about the usefulness of this. But since git was my first real vcs (10 years ago), it may just be that I have not used a workflow that took advantaged of persistant branches. I assume that
git annotatecould be a solution here.That’s absolutely true but I’m not sure it’s a real issue. Given how many strategies there are for CI/CD (and none is the definitive winner yet) I do think that being able to select the right option for you/your team/your org is probably a good idea.
I highly disagree about that xkcd comics. Git is compatible will all workflows so you have to use a subset of all the commands. Of course you will have more commands that you never use if a software is usable for all the workflow that you don’t use. But you need about 15 commands to do stuff, 30 to be fluent, and some more to be able to help anyone. Compared to any other complex software that I use I really don’t think that it’s an unreasonably high count. That being said I totally agree that git from 10+ years ago was more complex and we should correctly teach what is needed to junior. HTML/css/js is a nightmare of complexity but it doesn’t stop 15 years old kid with no mentoring to build cool stuff because you don’t need to know everything to be able to do most of the things you may think of, just a good minimal set of tools. And people should definitively take the time to learn git, and stop using outdated guide. Anything that don’t use
git switch,git restoreandgit rebase --interactiveand presents you have to inspect the history in length (git log --graphor any graphical interface that show the history in a graph,git show, and more generally than you can filter the history in any way you want, being by author, date, folder, file type, …) is definitively not a good guide.To sum-up, I think that from this presentation fossil seems more opinionated than git which means that it will be simpler as long as your workflow exactly matches the expected workflow whereas using git requires to curate its list of commands to select only the one useful for yours.
Thanks for this write-up!
It seems that you've kinda confirmed the points made by the Fossil team by showing that while all of their pain points are addressable, addressing those pain points takes more knowledge and experience compared to Fossil's implemented solutions. Opinionated workflows are best presented up front for beginners. It's no surprise that people with experience and have developed their own workflows already wouldn't value this highly unless they are often charged with helping beginners learn a git workflow.
Oh wow, I didn't know about this one. I guess it's relatively new?
Is it just a convenience command to try and be more specific (less multi purpose) than
git checkoutfor switching branches or does it bring any extra benefit? ...I'm already quite used to mygit coalias, to the point that it's almost hardwired to my fingers by now :PYes
git restoreandgit switchwere made specifically to be simplified, more specific commands which are safe from performing destructive actions without warning. They were implemented in Git 2.23.0 in 2019.2019, so 4-5 years ago so not that recent but not ancient either. But unfortunately tutorials have not been updated.
I would say that the biggest benefit of
git switchis that you can't switch to a detached state without using a flag (--detachedor-d). If you dogit co $tagorgit co $sha-1you may get at one point the error “you are in a detached state” which is ununderstable for begginers. To get the same error withgit switchyou must explicitely usegit switch --detached $tag/$sha-1which makes it much easier to understand and remember that you are going to do something unusual.More generally it's harder to misuse
git switch/git restore. And it's easier to explain them since the only do one thing (unlikegit checkoutwhich is a mess !).So if it's only for you
git checkoutis fine, but I would still advice to usegit switchandgit restoreso you will have an easier time to teach/help begginers.I am in a perpetual wonderland of git confusion, but this was a good read. And maybe I now have a pathway to enlightenment.
If you try to learn git one command at a time on the fly, git is HARD. If you take the time to understand its internal data structure it's much, much easier to learn. Unfortunalely most people try to do the former because it works well (or better) for most tasks.
I can't recommand enough the git parable.
Thanks. I guess it's the perpetual problem of learning something new. Instead of starting at the beginning, we trick ourselves into thinking that we can skip the fundamentals. Then we have difficulty and think that the problem is one of complexity or just over our heads instead of our approach.
In fairness, sometimes it is useful to get hands on experience with a system before you dig into its fundamentals so that you have a reference point that helps you absorb the information.
https://learngitbranching.js.org Is a very accessible browser game that I found useful on my Git journey to start to grasp the underlying structures and operations such as rebase.
Thanks
I use Fossil for all of my personal projects. Having a wiki and bug tracker built-in is really nice, and I like the way repositories sync. It's perfect for small teams that want everything, but don't want to rely on a host like GitHub or set up complicated software themselves.
Looks like it's written in C of all things, huh
inb4: Rewrite it in Rust!
Rewrite in Brainfuck!
This sounded interesting years ago. I never really looked into it though. Hopefully it's stabilized.
I'm just realizing that I was thinking of Pijul
There are still no built-in CI/CD, artifacts repository and AI assistant? Awful!
::: spoiler spoiler sarcasm :::
Ooh awesome. The more alternatives to git the better. I'm still bitter over Bitbucket dropping hg support. Suppose with this there's no need for a bitbucket.
Having the core of the repo being a sqlite DB is neat. Certainly seems better than needing external tools like I saw posted a couple days ago to do the same sort of queries. Of course literally any vcs is going to have better CLI UX than git, so not sure how much credit I can give fossil there.
I checked out fossil once and looks like it doesn’t have an equivalent to Pull Request so I moved on. It wasn’t clear how anyone could begin to be a contributor to a project if I host on fossil.
I mean, Git doesn’t natively have pull requests either…the “official” method involves sending patches through email. It seems that Fossil has a similar setup (although without the tool)..
PRs are a feature introduced by GitHub.I guess Fossil bundles would be close enough to them.EDIT: I was wrong. Turns out Git does have a pull request feature. It requires you to upload your code to a public repository, after which it generates a message asking to pull, which can then be sent via any medium to the repository owner. It doesn’t require patches, or GitHub. Differences to note: these aren’t like GitHub/Gitlab/Gitea pull requests, where you’re given a simple web interface and have to merge from a repository on that instance. Your repository can be hosted anywhere using
git request-pull. You’ll most likely then send the request through email, and get feedback in the form of replies. If you push newer changes to that branch, you’ll have to request another pull, asrequest-pullonly specifies a commit range. But yeah, I guess got technically does have pull requests. (For the scope of OP’s question however, I don’t believe he meant this.)This is objectively wrong! Git has 'request-pull' command that generates a message to an upstream maintainer to pull changes from an online downstream clone. That request message can be sent by email or some other means. But no patches are involved. And no - Github did not invent it. It was there before Github existed. In fact, there is a rant by Torvalds as to how GitHub reimplemented PRs poorly, throwing away good features of the request-pull command.
Thank you for that information. I had no idea that command existed, I guess because primarily I’ve seen people sending patches over email. I’ve updated my original comment with additional information. Thanks for calling me out 😅
Can I interest you in a Torvalds rant?
I didn't see the diff command last time, thanks for that. It still feels like a miss for fossil to host a web view and forum but not a pull request-like section.
Patches have terrible UX. IMO, if projects don't support the equivalent of pull or merge requests, they are just turning away contributors.
...ew.
One of the strengths of open source is its diversity of technical solutions. It's a feature, not a bug.
Before git, there were other open source version control systems, and they still work. For example, sometimes a centralized repository is the right tool for the job, and subversion is still there.
Fossil is cool. Almost no one uses it, aside from sqlite themselves, so it sort of feels like a roll-your-own VCS. But it works for them, and I suspect it would work for a lot of other people too.
sqlite has some interesting philosophical foundations, and that makes it an unique project. :)