Fossil, is it possible to have 2 leaves in single branch?

Question

Each branch has one leaf at any time. These represent the most recent state of the repository from the perspective of each branch. As your post mentions, branches are used to afford parallel developments within the repository. They are also created automatically (called a "fork" in such a case) to prevent two commits to same branch when each commit has the same immediate ancestor... allowing this would be just like having multiple leaves on the same branch.

To create a new branch of development, one opens a fossil repo and executes a command like:

fossil branch new some_feature trunk

Complete example

For the sake of example, I quickly created a new repository and added a single file to the trunk (the only branch initially), file.txt. The initial contents of my example file are:

here
is
a
file

After committing the added file with the comment, "create baseline", I created a development branch for a new feature called "some_feature" based on the current state (aka the leaf) of the trunk branch...

fossil branch new some_feature trunk

Now there are two branches, trunk and some_feature. Creating the branch does not change my working branch, so I am still in trunk. Then I edited the baseline file to:

here
is
a
file
folder

...adding "folder" to the end. Then I committed the change to trunk with the comment, "modification on first branch... trunk. Then I switched development to the some_feature branch...

fossil co some_feature

From this second branch, I also edited the last line of the baseline file:

here
is
a
file
reader

...adding "reader" to the end. Then I committed the change to some_feature with the comment, "modification on second branch... some_feature".

To merge development, you chose the branch you want to merge changes into. In this case, I will merge the feature branch changes into the trunk. To do this you must first checkout the destination branch for the merge... in my case, trunk.

fossil co trunk

Then, I merge in the change from the specific commit of the other branch. In my case, I'll use the leaf of that branch:

fossil merge some_feature

    MERGE file.txt
    ***** 1 merge conflicts in file.txt
    WARNING: 1 merge conflicts
    "fossil undo" is available to undo changes to the working checkout.

This leaves me with four files now in my working directory instead of one. No new commit/checkin has actually made it back to the repository proper. The four files are: file.txt, file.txt-baseline, file.txt-merge, and file.txt-original. "file.txt-baseline" is the file as it existed in the most recent common ancestor of the merging branches. "file.txt-original" is the file as it existed in the target brach, in my case, trunk, just before the merge. "file.txt-merge" is the file as it existed in the branch you were merging from, in my case, some_feature. Finally, "file.txt" contains the contents of the baseline file with conflicting changes from the original and merge files annotated so you can decide how to deal with the differing contents.

In my case the generated conflicts file, "file.txt" looked like this:

here
is
a
file
<<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<<
folder
======= COMMON ANCESTOR content follows ============================
======= MERGED IN content follows ==================================
reader
>>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Until the merge conflict annotations are removed from the file, fossil will not let you commit (or it will at least warn against it). Otherwise, you would make a commit with message, such as, "merged some_feature into trunk".

For reference, here is the event history diagram as provided by fossil for this example:

Fossil generated event history for my example project