• From Git To Fossil SCM

    From Ben Collver@bencollver@tilde.pink to comp.misc on Wed Nov 19 17:11:27 2025
    From Newsgroup: comp.misc

    From Git to Fossil by Lucio Albenga
    ===================================

    Published on 2025-11-12

    People at Git has started to work on a proposal to make the Rust [1] 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 documentation [2] 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 Git [3] 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 documentation [4] has the following example to export a Git
    repository and import it as a Fossil repository:

    +-------------------------------------------------------------------+
    | cd repository_name |
    | 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 geit 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 "your@mail.com your_username" \ |
    | repository_name.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 "your@mail.com your_username"' option changes the
    email address "your@mail.com" 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 "your@mail.com your_username" \ |
    | --attribute "rms@gnu.org rms" \ |
    | --attribute "linus@kernel.org 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:

    1. Go to the repositories folder in your server.

    2. If you don't have Sqlite installed, install it following the usual
    method of your operating system.

    3. Open repository.fossil with Sqlite:

    +--------------------------------------------------------------+
    | sqlite3 repository.fossil |
    +--------------------------------------------------------------+

    4. 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).

    5. 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 Book [5].

    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.

    Tip:

    Because Fossil has this clear separation between the repository file
    on one hand and the working folders on the other, I keep all the
    *.fossil files inside a folder named fossils in my /home and I have
    the working folders where is most appropiate in each case.

    Getting Info
    ------------

    For getting the information about the working folder and repository
    status there are some differences compared to Git, especially in the
    name and use of the commands.

    Viewing the timeline
    --------------------

    In Fossil the fossil time and fossil timeline commands are the
    equivalent of Git's git log command. Here are some examples from the
    one that provides less information to the one that provides more:

    +-------------------------------------------------------------------+
    | fossil time --oneline # similar to git log --oneline |
    | fossil time |
    | fossil time --medium |
    | fossil time --verbose # similar to git log | +-------------------------------------------------------------------+

    Viewing changes in your working folder
    --------------------------------------

    To see the changes in your working folder compared to the repository
    there are several commands and each one of them has different
    options.

    To see which files and folders are not under version control:

    +-------------------------------------------------------------------+
    | fossil extras | +-------------------------------------------------------------------+

    To see files that are under version control and have been modified:

    +-------------------------------------------------------------------+
    | fossil changes | +-------------------------------------------------------------------+

    To see a combination of the two previous commands:

    +-------------------------------------------------------------------+
    | fossil changes --differ | +-------------------------------------------------------------------+

    To see the working folder and repository status in a way more closely
    to the output of Git's git status command:

    +-------------------------------------------------------------------+
    | fossil status --differ | +-------------------------------------------------------------------+

    Viewing the Diff(erences)
    -------------------------

    To see the differences between the contents of our files in the
    working folder and what is in the repository, Fossil, like Git, has
    a diff command:

    +-------------------------------------------------------------------+
    | fossil diff | +-------------------------------------------------------------------+

    To see the differences between a specific commit and the working
    folder:

    +-------------------------------------------------------------------+
    | fossil diff --from 2c26dd6 # 2c26dd6 is the hashtag of the commit | +-------------------------------------------------------------------+

    To see the differences between two specific commits:

    +-------------------------------------------------------------------+
    | fossil diff --from 2c26dd6b69 --to cd086a1045 | +-------------------------------------------------------------------+

    Fossil's diff command doesn't show colorized diffs. Check out the Wiki
    if you want colorized diffs [6]

    Getting changes
    ---------------

    Fossil has an option called autosync that is enabled by default.
    This option keeps your local repository synchronized with the remote repository. If you have the autosync option enabled, you can get all
    the changes from the remote repository (if any) with the command:

    +-------------------------------------------------------------------+
    | fossil update | +-------------------------------------------------------------------+

    Otherwise it would be more similar to Git's. You have to do first a
    pull to get the changes and then an update for these to appear in
    your working folder:

    +-------------------------------------------------------------------+
    | fossil pull fossil update | +-------------------------------------------------------------------+

    Commiting changes
    -----------------

    As Fossil does not have the staging area, the commit is much more
    likely to version control systems like Subversion than Git.

    If you want to make a commit with all the pending changes:

    +-------------------------------------------------------------------+
    | fossil commit | +-------------------------------------------------------------------+

    The command above will open an editor for you to enter the commit
    message, but you can also provide the commit message as an option:

    +-------------------------------------------------------------------+
    | fossil commit -m "My commit message" | +-------------------------------------------------------------------+

    You can commit specific files with:

    +-------------------------------------------------------------------+
    | fossil commit file1 file2 |
    | fossil commit file1 file2 -m "My commit message" | +-------------------------------------------------------------------+

    If you have the autosync option enabled, the commit command will also
    send your changes to the remote server (if any). Otherwise you'll
    have to send the changes to the remote server with the command:

    +-------------------------------------------------------------------+
    | fossil push | +-------------------------------------------------------------------+

    Adding and deleting files
    -------------------------

    When you need to put new files under version control you can do it
    with:

    +-------------------------------------------------------------------+
    | fossil add filename | +-------------------------------------------------------------------+

    If you want to remove a file from the version control you can do it
    with:

    +-------------------------------------------------------------------+
    | fossil delete filename |
    | fossil rm filename | +-------------------------------------------------------------------+

    By default the rm and delete commands do not physically delete the
    file from the file system, they simply mark it as no longer under
    version control.

    There's also a command 'fossil addremove' which adds to the repository
    all the files in the working folder that are not under version control
    and removes from the repository all the files that are under version
    control but that no longer exist in the working folder.

    Ignoring files
    --------------

    Configuration is one of the points where there are several important differences between Fossil and Git, so I recommend you to check out
    Fossil's documentation. To ignore files and folder you have to create
    the file .fossil-settings/ignore-glob inside the working folder:

    +-------------------------------------------------------------------+
    | cd working_folder/ |
    | mkdir .fossil-settings |
    | touch .fossil-settings/ignore-glob | +-------------------------------------------------------------------+

    Then edit it using glob patterns [7]:

    +-------------------------------------------------------------------+
    | build/ |
    | 3rdparty/ |
    | *.o |
    | */a.out | +-------------------------------------------------------------------+

    Branches and Tags
    -----------------

    Git's paradigm encourages an intensive use of branches and tags but
    Fossil's paradigm and features are different so the workflows are
    different too.

    As I don't make much use of branches in my personal projects, I think
    that in order for you to get an idea of the differences so that you
    can adapt Fossil's features to your workflow, or your workflow to
    Fossil's features, you better read the following links from the
    Fossil Wiki:

    * Fossil Check-Out Workflows
    <https://www.fossil-scm.org/home/doc/trunk/www/ckout-workflows.md>

    * Fossil Branching, Forking, Merging, and Tagging
    <https://fossil-scm.org/home/doc/trunk/www/branching.wiki>

    * Fossil Private Branches
    <https://fossil-scm.org/home/doc/trunk/www/private.wiki>

    Local web interface
    -------------------

    I don't want to finish this little Fossil guide without making it
    clear that you can access and use the web interface without having a
    Fossil server. To do it, run the following command from within the
    working folder:

    +-------------------------------------------------------------------+
    | fossil ui | +-------------------------------------------------------------------+

    Final Thoughts
    ==============

    I like Fossil very much and, in my opinion, it's an almost perfect
    mix between a centralized version control system like Subversion and
    a distributed one like Git. I like how easy is to put it in server
    mode, its web interface and, above all, the simplicity of its command
    line and of the most common tasks.

    I think it's a great program that has a lot to offer, especially to
    indie programmers and small groups who are interested in self-hosting solutions. If you are looking for a simple and effective alternative
    to Git do not hesitate to take a look at Fossil because it may be
    exactly what you are looking for.

    References
    ==========

    [1] Git Mailinglist: [PATCH RFC 0/3] Introduce Rust and announce that
    it will become mandatorty
    <https://lore.kernel.org/git/20250904-b4-pks-rust-breaking-change-
    v1-0-3af1d25e0be9@pks.im/>

    [2] Fossil's Wiki
    <https://fossil-scm.org/home/doc/trunk/www/permutedindex.html>

    [3] How To Mirror A Fossil Repository On GitHub
    <https://fossil-scm.org/home/doc/trunk/www/mirrortogithub.md>

    [4] Import And Export To And From Git
    <https://fossil-scm.org/home/doc/trunk/www/inout.wiki>

    [5] Fossil Book
    <https://fossil-scm.org/schimpf-book/index>

    [6] Fossil Colorized Diffs
    <https://fossil-scm.org/home/doc/trunk/www/colordiff.md>

    [7] Fossil File Name Glob Patterns
    <https://fossil-scm.org/home/doc/trunk/www/globs.md>

    * * *

    (c) 2025 Lucio F. Albenga - All Rights Reserved

    From: <gopher://lucio.albenga.es/0/lfa/en/articles/2025/ 20251112-from_git_to_fossil.txt>
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.misc on Wed Nov 19 20:25:06 2025
    From Newsgroup: comp.misc

    On Wed, 19 Nov 2025 17:11:27 -0000 (UTC), Ben Collver wrote:

    * 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.

    The need for explicit git-add is very useful even in single-person
    projects.

    For example, I spend several hours making and testing a bunch of
    changes to the working source tree. At the end of it, once I’m
    satisfied the code has reached a suitable point, I realize that my
    changes are more naturally grouped into multiple commits, rather than
    a single one.

    So now I use “git add -e” and review the resulting patch, putting
    together the first commit by taking out everything I want to leave for
    later commits. Then I commit what’s left, with a suitable
    descrfiption.

    Back into “git add -e” again, to put together the next commit, and so
    on, until it’s all done. Except I might leave out some debug lines,
    that I don’t want to include in the final source.

    In the process, I might hand-edit a line here and a line there, to
    disentangle separate changes for which the source only holds the
    combined effect. This means creating intermediate versions of the
    source code that never actually existed as explicit files in the
    source tree.

    Git gives you the flexibility to work this way, if you choose.

    * 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.

    There was never a requirement for you to use *valid* email addresses
    ...
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Eli the Bearded@*@eli.users.panix.com to comp.misc on Thu Nov 20 04:50:02 2025
    From Newsgroup: comp.misc

    In comp.misc, Ben Collver <bencollver@tilde.pink> wrote:
    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.

    You do you, but I generally let tool developers pick the language they
    like for their tool and just use the output. (If I have to compile it
    myself, the newer languages are a little more suspect because they tend
    to be very picky about which version you compile with, but mostly I
    don't compile myself, I use the packaged version.)

    To me, the really problem with git, besides the god awful command line
    usage, is the reliance on an unchanging scheme for commits, sha-1. A
    more flexible system would allow switching to another scheme as
    collision effort warrants.

    Rust, C, Go, Pascal, Scheme, Lisp, or even C++ for the tool: who cares?

    Elijah
    ------
    always had a softspot for Perforce, but not Perforce licensing
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.misc on Thu Nov 20 08:17:35 2025
    From Newsgroup: comp.misc

    On Thu, 20 Nov 2025 04:50:02 -0000 (UTC), Eli the Bearded wrote:

    To me, the really problem with git, besides the god awful command line
    usage, is the reliance on an unchanging scheme for commits, sha-1. A
    more flexible system would allow switching to another scheme as
    collision effort warrants.

    Patches have been going in, gradually, to facilitate that. Nobody involved with Git seems to think there is any urgency to abandon SHA-1.

    <https://git-scm.com/docs/hash-function-transition>
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From ram@ram@zedat.fu-berlin.de (Stefan Ram) to comp.misc on Thu Nov 20 08:40:32 2025
    From Newsgroup: comp.misc

    Eli the Bearded <*@eli.users.panix.com> wrote or quoted:
    In comp.misc, Ben Collver <bencollver@tilde.pink> wrote:
    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.
    You do you

    He did Lucio, not Ben.


    --- Synchronet 3.21a-Linux NewsLink 1.2