Actually, the convention for remotes on a fork usually is:

• origin: points to the fork repo on GH.
• upstream: points to the upstream repo on GH.

I wasn't aware there was a remote called icub-tech, which would be peculiar to our system and not created at clone time.

Actually, the convention for remotes on a fork usually is:

• origin: points to the fork repo on GH.
• upstream: points to the upstream repo on GH.

I wasn't aware there was a remote called icub-tech, which would be peculiar to our system and not created at clone time.

Actually, the repo gets cloned by the super build using robotology as origin. I thought it would be less error prone specifying a different remote name for the robot workflows only. This also enforces the good practice of not changing origin when adding a new fork to the repo

Actually, the repo gets cloned by the super build using robotology as origin.

I see, I missed this point.
Then, I would explain somewhere in the instructions that icub-tech is the remote pointing to the fork.

Then, I would explain somewhere in the instructions that icub-tech is the remote pointing to the fork.

It's already introduced here:

• robots-configuration/.github/local-workflow-tech.md

  Line 15 in 2847adc

  git remote add icub-tech https://github.com/icub-tech-iit/robots-configuration.git