I think I have a fundamental misunderstanding regarding branches. The branch doesn't appear to change when I try to switch.

imac3 [~/Desktop/moca] > fossil update master
Pull from http://durian@myserver/moca
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, wire bytes sent: 413  received: 3651  ip: 192.168.1.2
-------------------------------------------------------------------------------
checkout:     22dc6f6589cd522bab3f7fc37b78437d2dc000ac 2022-05-20 20:12:00 UTC
tags:         develop, ivv, libcmsis, master, trunk
comment:      Merge IVV into master (user: durian)
changes:      None. Already up-to-date
imac3 [~/Desktop/moca] > fossil branch current
develop

My code base originated under git, which is why one branch is named master.

I merged develop info master, so both branches should have the same file. I didn't expect any source to change when I updated to the master branch, but I did expect the output from 'fossil branch current' to report master.

Can someone enlighten me as to what is happening (and perhaps what I screwed up).

Thanks, mike

I did expect the output from 'fossil branch current' to report master.

How do you expect it to choose from the plethora of choices you've given it? "tags: develop, ivv, libcmsis, master, trunk"

The difference between tags and branches in Fossil is whether they're auto-propagating. It looks like at least three of those tags are branches; I can't tell about ivv and libcmsis in your example.

The command's output will become more predictable when you get away from these five-way merge points, giving Fossil only one choice of answer.

I definitely didn't intend that to happen. All those tags are separate branches. Aside from trunk, they were all created in the original git repository.

Say I'm on branch develop. If I do 'fossil update ivv' do I need to do anything to stop the auto-propagating 'develop' tag from tracking any new changes? (At least until I do a 'fossil update develop' to return to the develop branch.)

I did merge develop into both ivv and master, so they should all contain the same thing. Does that implicitly make a three-way merge point? If so, how do separate things so my changes will only appear in one of them?

I didn't do anything with the libcmsis branch. I think that branch was only used briefly in the original git repository. I certainly haven't intensionally done anything with it since I migrated to fossil. I don't know why it is appearing now.

I think I am fundamentally misunderstanding how fossil handles branches compared to other control systems like perforce or git.

Aside from trunk, they were all created in the original git repository.

You might want to reimport the repo with --rename-trunk master so you don't have that bogus branch. Fossil should work fine without a "trunk" branch.

Either that, or use --rename-master, if you have no particular love for the "master" terminology.

There's no point in having both.

If I do 'fossil update ivv' do I need to do anything to stop the auto-propagating 'develop' tag from tracking any new changes?

If both are propagating along master, I think you're pretty well stuffed until you untangle things.

Try using Fossil's special check-in names for the root of a branch to work out what happened, which will guide you to a solution. Something like this:

 $ fossil up root:develop
 $ fossil status

Then do the same for the other branches. Once you find out where their roots originate, you may have a better idea of what to do about it.

You may also find the /timeline helpful. Say "fossil help /timeline" for ideas of ways to query the timeline to pull up points of interest.

I think I am fundamentally misunderstanding how fossil handles branches

It's quite possible. Git does not handle branches the same way Fossil does. (Details)

Does that implicitly make a three-way merge point?

Yes, but it doesn't cause those tags to propagate past the merge point.

It appears fossil does not actually track which branch you are working on.

Approximately true. Fossil tracks the parent check-in ID, not the parent's tag(s). When you commit, it does look at the branch names to ensure that you aren't about to create an unintentional fork, but other than that, Fossil only cares about those ugly 64-digit hex IDs. Names are mostly for the human's convenience.

One checkout might be on multiple branches.

Better to say that any given commit may have multiple propagating tags along its history, back to its root. In that situation, any of the names can be used as aliases for any commit along that line of development.

I'm not sure I've ever caused that situation. It's common enough to have one branch and one or more non-propagating tags, but multiple branch names? Weird.

Given that names are for the human's convenience, why would the human cause themselves confusion by setting such a situation up?

I'm not victim-blaming here. I'm pointing out that the situation you find yourself in is abnormal and unhelpful. You're best advised to untangle it, for your own sake.

If I now make a change and check it in, will it only update the develop tag/branch or will all the other tag/branches update too?

If you have multiple propagating tags up the line from the commit point, all of those branches will be updated.

Do I use the --branch argument to the commit command or is that reserved for new branches?

I believe you can use that flag as much as you like, but I don't see that it'll help you get out of this situation.

I have to wonder if this mess wasn't created in the Git repo, and Fossil is now faithfully showing you what you had in the old repo. Maybe something like reposurgeon or Git history filtering could clean it up, allowing you to reimport it without these problems.

If that isn't possible, I can only recommend that you cancel all these unwanted propagating tags, except for "master":

  $ fossil up master
  $ fossil tag cancel ivv
  ...etc...

Now you have a clean master branch, freeing you to reuse the other branch names to refer to new forks off of it. Commands like fossil ci --branch ivv will no longer be ambiguous.

Good luck, and may Merkle be with you!

Thank you for the detailed response. I've got enough regular tags marking important milestones that I think I can safely cancel most of my branches and start afresh.

I never had a problem using branches in other systems, but I suspect I've got a methodology that isn't suitable for fossil. In the spirit of avoiding getting into this situation again, do you have any thoughts on what I might have done to create this knot?

For example, I created the ivv branch from develop. I think I made a minor change or two in ivv and then merged back into develop. At this point develop and ivv would have been the same. Then I made many changes to develop and eventually merged them back into ivv. Again, the two branches would have be identical after the merge. Will actions like those create the sort of problem I am seeing?

Will actions like those create the sort of problem I am seeing?

Not in Fossil. Thus my speculation that the confusions were created in Git, and Fossil's just showing you the ugly truth.

Either that, or there's a bug in the converter. That would be another good reason to look into reposurgeon: to get a second opinion.

I took a quick look at the reposurgeon source code. I don't know go, so I might not have this correct, but it looks like reposurgeon relies on fossil's import and export function to convert fossil to git for processing.

Based on what I encountered converting my git repository to fossil, I do think there are problems with how fossil imports a git repository. If I am correct, then anyone using reposurgeon to work on a fossil repository might want to be careful. Reposurgeon might change the repository in unintended ways.

I've thought about this a little more. Let me know if I'm anywhere close to reality.

It appears fossil does not actually track which branch you are working on. It just sees a checkout that might have one or more tags applied to it. If those tags are self-propagating, then they are considered branches. One checkout might be on multiple branches. This is different from what I'd assumed was happening. That different branches might point to the same artifact(?), but they'd still be separate branches.

In my case, I've got one checkout that is tagged with five different self-propagating tags. fossil is reporting it as the develop branch because that happens to be the first branch tag it found.

If any of that is correct, I have some follow-up questions.

If I now make a change and check it in, will it only update the develop tag/branch or will all the other tag/branches update too?

If I want to make a change from here that should only appear in the ivv branch, how do I do it? Do I use the --branch argument to the commit command or is that reserved for new branches?

Can I even split things now that they have merged together?

tags: develop, ivv, libcmsis, master, trunk

To add to what Warren said: when you pass a symbolic name (like a branch name or tag) to fossil update:

fossil update master

fossil finds the most recent version with the given symbolic name. Any number of commits can have the tag master, but that update will resolve to the most recent one. In your case both master and trunk resolve to the same version.