I am experimenting with a child project, and have run into difficulty determining what is on the parent so I can reset to it.

The scenario is:

1. Clone parent to child
2. Commit some stuff in each one
3. Pull from parent to child

Demo script

This is now a fork. I decide in the child, I want to match what the parent considers to be trunk. I'm stuck though.

How do I see what the parent considers trunk? With git I would do git show origin/main. I've gone through the documentation and don't see any commands for inspecting the branches / leaves of a remote.

I think I have worked out how to revert to a specific commit. Please let me know if I'm misunderstanding something.

fossil tag cancel trunk <first-bad-commit>
fossil tag add --raw closed <leaf-that-is-no-longer-trunk>
fossil up trunk

Now, I just need to know how to view the trunk tags on a remote repo.

I started to write a long answer to this, but then I decided it'd be better simply to add this topic to our Git to Fossil Translation Guide. Assuming you have read it once already, the key changes are to the second paragraph up in the introduction, changes to the autosync section, and the addition of a new section on reset.

If you don't see that this answers your questions, you're free to continue this thread. Perhaps the new docs are incomplete and need improving; wouldn't be the first time.

Thank you! Very simple (now that I see an example :) I have updated my demo script to use this.

Now that I've seen this, I see that shunning "Alternative" demonstrates this as well - but since my brain is still... fossilizing? (seems undesirable) - I didn't realize that's what was happening.

Thank you for the translation from git!

only if the different commits are done on the same "branch" and against the same parent would it introduce a "fork"

Yeah, sorry, I didn't include the details in my original post, but that's the scenario I'm describing.

and then it is not said that the repository is a "fork", but rather that there exists a "fork" in the DAG (aka timeline) in one or both of the repositories.

Understood - thank you for the correction.

You probably don't want to mess around with the "fossil tag" command

I took that from the wrong way to close a branch. I will look into the difference between amend --close and branch close.

If you're using SSH, then you would want a "parent" clone that is local so you can use "fossil ui" with it. That way you can "see" what the "parent" has.

While I appreciate a lot that the ui offers, I want to answer questions like this from the command line. You've helped me do that:

ssh remote "fossil info trunk -R path/to/my.fossil

also, have a local undisturbed clone

Hope this helps.

Very much so, thank you!

One thing I'm taking away from this is that branches should eventually resolve to the same thing. That is, if I'm using child projects to make a closed-source enhancement, then I should have a separate branch e.g. my-trunk which is trunk + my enhancements, and keep trunk matching upstream trunk exactly. Is that right?

One thing I'm taking away from this is that branches should eventually resolve to the same thing. That is, if I'm using child projects to make a closed-source enhancement, then I should have a separate branch e.g. my-trunk which is trunk + my enhancements, and keep trunk matching upstream trunk exactly. Is that right?

Yes. I would suggest either renaming the child's trunk or keeping a separate branch for the child's mainline development.

I have a child repo (which I would consider a repository fork since it can never push back to its parent).

The child repo does mainline development on the trunk branch. When I pull from the parent, I get two trunk branches (which is allowed by fossil). The DAG has a fork at the point before my first commit to the child repo.

The parent repo is more active than the child. When I pull the parent into the child I them merge this way

1. in a checkout/update to the last commit on the child's trunk
2. merge trunk (which is the tip of the parent's trunk since it is the newest commit)
3. test, commit
4. merge child trunk into all child branches (or sometimes merge the tip revision on the parent's trunk by hash into a child branch)

All in all it's confusing that there are two branches named "trunk" that have to be merged. I have wasted time trying to figure out why my commands weren't working. So I suggest renaming the child's mainline to something like default or main starting with the first commit on the child. You may be able to just rename that point in the GUI, I haven't tried. But I may try on a copy of the repo to see if it works as I expect.

I think you are trying to apply the Git worldview to Fossil. I think you may be assuming that those two systems work exactly the same. They do not.

I've run a million git commands over the years, so there is a lot of rewiring to do :) I really appreciate how patient and informative people are around here.

Abandoning one arm of a fork

Yep, I didn't know how to do that and couldn't figure it out... "rename the branch" makes sense in retrospect, and is a clear example of where I need to re-learn things in Fossil.

There is no "my repo", "your repo", "Alice's repo" - all the repositories hold everybody's stuff (almost) all of the time.

I think there is one exception: child projects.

Here, there is "their repo" (upstream) and "our repo" (proprietary). So there is some need to understand what is on "their repo" so we can merge it into "our repo".

How do you handle this in practice? Does your proprietary repo trunk track upstream trunk, and you have a separate proprietary-trunk branch that is trunk + any of your proprietary changes? Or do you merge all upstream and proprietary changes to trunk on your child project?

Just FYI Child Projects/child repos (rather than a cloned repo) seem to be a niche mechanism that is not widely used. IIRC I asked a question a while ago about it and Richard had forgotten about child projects and didn't initially make the connection.

I don't wish to discourage you from using it, but I just wanted to say there isn't really a best practices knowledgebase about it.

Regarding renaming the main branch, see my comment above. TL;DR rename it.