Pangram verdict · v3.3
We believe that this entire text is human-written.
AI likelihood · overall
HumanArticle text · 1,578 words · 1 segments analyzed
From Git to Fossil People at Git has started to work on a proposal to make the Rust1 programming language mandatory. I don't like Rust and, above all, I don't like its community of little extremist characters who are trying to make everyone swallow their crap by rewriting projects that have been working for decades, doing social media brigading, and other nice little gems worthy of any tiny group with totalitarian delusions. That's why when I see that a project aims to "force" the use of or the switch from C to Rust, to the extent of my possibilities, I flee from it as if I were pursued by the Balrog of the Lord of the Rings with his whip. I'm old enough to have used (or tested) many version control systems: RCS (Revision Control System), CVS (Concurrent Version System), SVN (Subversion), HG (Mercurial), BZR (Bazaar), and the aforementioned Git, which means I have no problem in switching again, so I started to think about a Git substitute for my personal projects. The options were to go back to one of the already known or look at something else, and I remembered Fossil. I started looking over the source code and reading the official documentation2 to learn its features, its dependencies, how to install and configure it, etc., and I noticed it had many things I like: It's made in C (although it uses some js and tcl for its web functionality) and is a small and efficient program that consumes few hardware resources. It's simpler to use and it feels more natural (at least for someone who knows other systems such as Subversion) because it does not contain overkill functionalities such as the staging area, which may be useful in large and complex projects such as the Linux kernel, but for me they have no practical use. It allows you to self-host a server on your own quickly and easily because it is already prepared for it. In fact it has a web server and a web interface with version control views, wiki, tickets, etc. On the other hand, with Git you have to use an external software such as GitLab, Gitea or Forgejo, and each one of them is at least one extra software dependency. Commit messages don't use email addresses, they use user names so if you have a public repository you don't have to be worried about spam and you don't need a specific email address for this use only. It's interoperable with Git in the sense that if there is a need to change a repository back to Git you can do it and it also supports two-way synchronization between a Fossil repository and a Git3 one (this is the functionality used by Fossil and Sqlite projects to manage their GitHub mirrors). Taking all this into account, I decided to install Fossil and switch my projects from Git. Below you'll see how to do it. Installing Fossil The first step is to install Fossil and it's quite likely that the package manager of your operating system already has it available: sudo apt install fossil # Devuan GNU+Linux pkg install fossil # FreeBSD Once your package manager ends the installation you can check its availability with the following command: fossil version The command above should return something like the following: This is fossil version 2.21 [3c53b6364e] 2023-02-26 19:24:24 UTC Importing Git repositories Fossil's documentation4 has the following example to export a Git repository and import it as a Fossil repository: cd repository git fast-export --all | fossil import --git repository.fossil I did it differently because I wanted to adjust some things to have the imported repositories "right". As I have several repositories I created two different folders, one, git-exported, to store the exported repositories and another one, fossils, to store the new Fossil repositories: mkdir ~/git-exported mkdir ~/fossils Now you can get into each Git repository folder and export it: cd repository git fast-export --all > ~/git-exported/repository.export Once you have exported all your Git repositories you should go inside the ~/fossils folder and import them one by one with the command: fossil import --git \ --rename-master trunk \ --attribute "[email protected] your_username" \ repository.fossil ~/git-exported/repository.export The --rename-master trunk option renames your Git master branch as trunk in your new Fossil repository. Fossil, like other version control systems such as Subversion, uses trunk as the name of the master branch. If you are among the unfortunate ones who have their master branch named as "main" this option is not for you and you should check Fossil's documentation if you want to rename it. The --attribute "[email protected] your_username" option changes the email address "[email protected]" from Git commits to "your_username" in the imported Fossil commits. In Fossil the default username is the same as the one you're currently using in you operating system. Obviously the given email address should exist in one or more commit messages. If you want to change more than one email address you can do it using several --attribute options: fossil import --git \ --rename-master trunk \ --attribute "[email protected] your_username" \ --attribute "[email protected] rms" \ --attribute "[email protected] torvalds" \ repository.fossil ~/git-exported/repository.export The output of the import command looks like the following: Rebuilding repository meta-data... 100.0% complete... Vacuuming... ok project-id: e64b112b40eb3db188060ddb8deeaa96a6ad3b71 server-id: bfbcd4bf8f0f64eaa2d832ddc3b4af00639624a6 admin-user: your_user (password is "XAxPVZcNQ6") If you look closely, the output gives you the repository administrator's user and password. Keep it because you'll need it to do certain things on your repository. Setting Up a Fossil Server Fossil has an embedded web server so you can take advantage of it to create a self-hosted server quickly and easily. The following method is enough for a system with few users, in a private network that cannot be accessed from the outside. There are different ways to set up a Fossil server and some are better than others depending on your needs, so I recommend you to check out the official documentation. First you should create a folder to store the Fossil repositories on the server: mkdir /path/to/your/fossils Next copy your "fossils" to the folder on the server: scp *.fossil user@your_server:/path/to/your/fossils/ Now you can start the server with the following command: fossil server --port 8043 \ --cert /path/to/your_cert.pem \ --pkey /path/to/cert/key.pem \ --repolist /path/to/your/fossils/ If you don't have a valid certificate you can use the follwing command: fossil server --port 8043 \ --cert unsafe-builtin --repolist /path/to/your/fossils/ Once the server is running, if you put the following url https://server_address_or_hostname:8043/ in your browser you'll access a web page with the list of your repositories. If you click on one of the repositories listed, you'll see the repository web page. In the navigation menu you should see a "login" option. Click on it and use the repository administrator's username and password. Now you can configure the repository to your liking. Check out Fossil's documentation to learn more. If you lost your Fossil repository administrator's password, you can recover it by following these steps: Go to the repositories folder in your server If you don't have Sqlite installed, install it following the usual method of your operating system. Open repository.fossil with Sqlite: sqlite3 repository.fossil Once inside sqlite execute the following query: select login,pw from user; The query above will return something like: your_user|My3w2jRxt1 anonymous|57EBCBD1AAE663B4 nobody| developer| reader| The password is the value on the second column (in this example the string My3w2jRxt1). Exit Sqlite with the following command .quit Using Fossil Here is a very brief guide on how to start working with Fossil. This guide assumes that you know how to use Git, at a very basic level, and it's just a starting point, so I recommend you to read Fossil's documentation and the Fossil Book5. Getting Help The help command is essential to see which commands are available and the uses and options of each one of these commands. The help command works just like Git: fossil --help fossil command_name --help Creating and cloning repositories These are similar to Git's but with differences. In Git it's usual that the repository matches the current working folder. In Fossil this is not so, there is a clear separation between the repository, file repository.fossil, and the working (check-out) folder repository_folder. Creating a repository You can create a new repository with the command: fossil init repository.fossil This command will create only the repository, i.e. the file repository.fossil. To start working with it you have to "open it". Create a folder, move inside it, and open the repository: mkdir my_working_folder cd my_working_folder fossil open /path/to/repository.fossil You can also tell Fossil the name of the working folder and if it does not exist Fossil will try to create it: fossil open --workdir my_working_folder /path/to/repository.fossil Cloning a repository You can clone a repository using the command fossil clone followed by the repository url. The url can be a web url, a ssh url, a file path, etc.: fossil clone https://host/repository This command will automatically download the file repository.fossil and it will create, at the same level, the working folder repository_folder. If you don't want it to create the working folder you can do it by using the command like: fossil clone --no-open https://host/repository Once the repository is cloned, if you want to send your commits to the remote repository (and you have permissions for it), you should configure inside the working folder the remote fossil repository: fossil remote https://user@host/repository The command above will asks you for your user's password and it will also asks if you want to save it for future use.