When I initially created my fossil repository, I migrated from git using the 'fossil git' command. I must have used the --mainbranch option because I don't have a 'trunk' branch. I have a 'develop' branch instead. For consistency with new fossil repositories, I'd like to rename the 'develop' branch to 'trunk'. I'm not sure how I should go about doing this. Is it enough to create a new branch named trunk that is a duplicate of develop and then close my develop branch or is there more to it?

Thanks, mike

Try:

  fossil amend --branch trunk develop:root

If not that, then the literal commit ID at the root of your develop branch.

This won't rewrite the artifacts, because that would change all the hashes, but it should cause the UI to display "trunk" instead of "develop" everywhere.

That special name should probably be start:develop.

I think I made things worse.

I did

fossil amend --branch trunk start:develop

This created a new trunk branch. The develop branch was also still present after the command. However, the start branch was different from the develop branch (fossil diff --from develop --to trunk). Trunk seemed to be missing some changes.

I tried the command again and now my develop branch is gone and trunk still doesn't contain the most recent changes.

Here's the most recent entries in the timeline:

=== 2023-02-13 ===
23:39:37 [07eede2e3e] Edit [135a8e985209de52|135a8e9852]: Move to branch
         [/timeline?r=trunk&nd&dp=135a8e985209de52&unhide | trunk]. (user:
         durian)
23:37:26 [7d6d01b9c0] Edit [77ec273818446a9b|77ec273818]: Move to branch
         [/timeline?r=trunk&nd&dp=77ec273818446a9b&unhide | trunk]. (user:
         durian)
18:41:25 [58eaeb8d0a] Update README with notes saying to include serialization
         in the silk and that the silk should be white. (user: durian tags:
         ra6m3)

I'm not sure what to do. How can I either restore things to before my first amend command (I do have one remote repository I haven't synced to since before the amend) or adjust the current situation such that trunk is up-to-date with the most recent 58eaeb8d0a change.

mike

While it is possible to remove the amendment, returning your tree to its prior state, at this point I'd just restore from backup and then apply the amendment to the tip of "develop" instead, so that going forward it will be called "trunk".

I've got two remotes, one that I haven't synced to and the other which is the default. I haven't explicitly synced since the amend, but I assume it was automatically pushed to the default remote. To restore from the non-default remote, do I need to delete my existing repository and then clone from it, or is there a command I can run that will ignore what I have and match the remote's state without accidentally pushing the amend changes?

As for the amend command itself, is this what you recommend?

fossil amend --branch trunk tip:develop

mike

I assume it was automatically pushed to the default remote

Why guess? Look at its timeline and find out.

do I need to delete my existing repository and then clone from it,

Better would be to restore from a local backup, which you do have, right? Right?

Fossil itself is not a perfect backup. If that's all you have, then I suggest you do back this confused repo up, then try an alternate plan first: cancel the amendment tag. You may be able to do this more easily in the UI by clicking on the initial commit to the repo and telling it to remove the branch rename.

If you can't work out how to do that, then yes, re-cloning is your next-best plan. It has one bad side-effect: you'll need to close and re-open your repos afterward since re-cloning changes the RID values referred to by the checkout DB.

is there a command I can run that will ignore what I have and match the remote's state without accidentally pushing the amend changes?

There isn't anything like "git reset --hard" in Fossil to globally throw away local history in favor of the remote, on purpose. The closest we have are surgical removals: tag cancel, amend hide/close, purge, shun…

fossil amend --branch trunk tip:develop

You don't need to give the tip: prefix. That's implied.

Sigh, backups would be nice. I do have backups in a normal situation, but recently the zpool backing store detected corruption issues and my most recent backup for the fossil database is too old to be useful.

I couldn't figure out how to cancel the tag either. My attempts didn't seem to do anything.

Recloning was a success, so I'm back to where I need to be. Yay! And thanks.

I redid the amend command and it worked better, but I'm still a bit confused about its behavior. When I do

fossil diff --from develop --to trunk

I see output. Specially, the trunk branch has three files that are no longer present in the develop branch. Did amend create the trunk branch from the most recent check-in to develop and then left develop without that check-in? I was expecting it to be more like a rename, where develop would become trunk in toto. I suspect you tried to explain this when you said:

This won't rewrite the artifacts, because that would change all the hashes, but it should cause the UI to display "trunk" instead of "develop" everywhere.

But the bit about rewriting artifacts went right over my head.

For those following along at home, I did check my default remote and the amend stuff did not automatically propagate.

Try out another path: fire up the UI, click on the first (oldest) checkin on the "develop" branch, click "edit", check "Make this check-in the start of a new branch named:" and say "trunk", then "Preview" and "Apply changes".

The CLI equivalent would be:

fossil tag add --raw branch=trunk --propagate start:develop
fossil tag add --raw sym-trunk --propagate start:develop
fossil tag cancel --raw sym-develop start:trunk

I will give this a try tomorrow. Can you explain what these commands do?

In Fossil, branch "affiliation" is implemented by means of (propagating) tags, so basically those commands remove the "develop" and add the "trunk" tag to all check-ins on that branch. I recommend reading Warren's detailed documentation.

For this case, using the GUI is certainly the more comfortable option - bearing scrolling to the first check-in on the said branch, but that shouldn't be too difficult, either.

Warren's detailed documentation.

While I did add a lot to the branching doc, that particular section is mostly drh's work.

Sorry - the power of habit 😉

I gave these commands a try (command line stuff is a little more intuitive to me than the UI interface). They created a trunk tag, but when I check to see what branches exist, trunk does not appear and develop is still listed.

> f branch list
 * develop
   ivv
   libcmsis
   mod0
   ra6m3
   release
   vendor/elm-chan/libfatfs
   ...

> f tag list
...
develop
ivv
ivv/1
ivv/2
libcmsis
mod0
ra6m3
release
...
trunk
vendor/elm-chan/libfatfs
...

I wonder if the problems I'm having changing the branch name are related to two earlier problems I had with this repository.

Back when I first created the repository, I imported the project history from git. This was not completely successful. There is a place where the git import code that doesn't check for a NULL value and goes ahead and dereferences the pointer anyway. I believe my git repository was tickling this bug..

Then I had a problem where all my branches were all propagating together. I believe this was due to the problems encountered when I initially imported the code.

I did cancel tags on my develop branch so it was only tagged with develop and not all the other ones. Perhaps a combination of the initial problem and the way I canceled tags has left me in the situation I'm in now where my attempts to rename the branch aren't quite working as expected.

I was familiar with the branching doc. I will read up on the file format doc and see if that helps clarify things for me.