Unclear purpose of primary_branch setting

[rosenrot00]

What happened

Setting primary_branch appears to have no impact on the update process; it is purely informational.

What is the purpose of this setting if it does not actually modify the repository? I would expect it to actually check for updates on the primary_branch as this would allow to simply switch branches by just changing the Moonraker.conf. If this isn't the purpose, I don't need this setting at all as I have to change the branch in terminal - or am I missing something?

I think issue #691 is related.

Client

Mainsail

Browser

Chrome

How to reproduce

1. Clone to git repo using a terminal command. This results in being in the master branch. git clone --filter=blob:none --sparse https://github.com/Phil1988/FreeDi
2. When hitting update in Moonraker, the branch stays on master even though the primary_branch was set to dev in Moonraker

Additional information

Moonraker section:

[update_manager FreeDi]
type: git_repo
path: ~/FreeDi
channel: dev
primary_branch: dev
origin: https://github.com/Phil1988/FreeDi
virtualenv: ~/klippy-env
requirements: requirements.txt
is_system_service: False
managed_services: FreeDi
info_tags:
desc=FreeDi
sparse_dirs:
- FreeDiLCD
- screen_firmwares

Moonraker Log:

Owner: Phil1988
Repository Name: FreeDi
Path: /home/mks/FreeDi
Remote: origin
Branch: master
Remote URL: https://github.com/Phil1988/FreeDi
Recovery URL: https://github.com/Phil1988/FreeDi
Current Commit SHA: 5ca6dd25840d2ab4f7b711769fd107cc203150d1
Upstream Commit SHA: 5ca6dd25840d2ab4f7b711769fd107cc203150d1
Current Version: v1.21-22-g5ca6dd25
Upstream Version: v1.21-22-g5ca6dd25
Rollback Commit: 5ca6dd25840d2ab4f7b711769fd107cc203150d1
Rollback Branch: master
Rollback Version: v1.21-22-g5ca6dd25
Is Dirty: False
Is Detached: False
Is Shallow: False
Commits Behind Count: 0
Diverged: False
Pinned Commit: None
Repo Warnings:
Repo not on offical remote/branch, expected: origin/dev, detected: origin/master
2025-01-08 09:49:27,857 [base_deploy.py:log_info()] - Git Repo FreeDi: Channel: dev
2025-01-08 09:49:27,857 [base_deploy.py:log_info()] - Git Repo FreeDi: Validity check for git repo passed
2025-01-08 09:49:27,936 [job_state.py:_handle_started()] - Job state initialized: standby
2025-01-08 09:49:28,189 [klippy_connection.py:_check_ready()] - Klippy ready
2025-01-08 09:49:28,455 [authorization.py:_check_trusted_connection()] - Trusted Connection Detected, IP: 127.0.0.1
2025-01-08 09:49:28,457 [application.py:log_request()] - 101 GET /websocket (127.0.0.1) [TRUSTED_USER] 3.40ms
2025-01-08 09:49:28,458 [websockets.py:open()] - Websocket Opened: ID: 281472846980624, Proxied: True, User Agent: Python/3.11 websockets/14.1, Host Name: localhost
2025-01-08 09:49:28,689 [data_store.py:_init_sensors()] - Configuring available sensors: ['temperature_fan MCU_fan', 'temperature_sensor Mainboard_RK3328', 'temperature_sensor Mainboard_STM32F407', 'temperature_sensor Toolhead_RP2040', 'heater_bed', 'heater_generic chamber', 'extruder']

[rosenrot00]

So the dev branch was removed and I had a dirty git which allowed me to "soft reset" via Moonraker. It seems soft reset does consider the primary branch, as I see the following error.

To me this is the right behavior but still, the primary branch should also be considered when checking for updates.

[Arksine]

Moonraker's update manager does not switch branches. The purpose of the primary_branch option is to allow Moonraker to pass repo validation checks when the current branch is not master. If the repo is on a branch that does not match the primary_branch Moonraker will warn the user. Put differently, its purpose is to alert the user if the repo is on an unexpected branch so the issue can be corrected.

So the dev branch was removed and I had a dirty git which allowed me to "soft reset" via Moonraker. It seems soft reset does consider the primary branch, as I see the following error.

Yes, the recovery API will attempt to reset the repo to the primary branch. It will only do so if the branch has already been created locally and has a remote tracking branch.

To me this is the right behavior but still, the primary branch should also be considered when checking for updates.

I disagree. The update manager is not intended to be a repo management tool. Its only purpose, with regard to git repos, is to pull updates on a repo that has been cloned and configured locally. Once an update_manager configuration section has been added there should be no reason for end users to change the branch. Switching branches, or creating a new branch, is dev work and should be done via the shell.

[rosenrot00]

Thank you for explaining the exact functioning and purpose of this setting. While I would have appreciated seeing Moonraker include minimal repository management capabilities to bridge the gap between standard users and developers, I understand the current approach. Such a feature could have allowed non-developers to manage specific repositories through the web interface.

That said, I respectfully disagree with your view that end users shouldn’t change branches. I believe certain users -particularly those enhancing their 3D printers with tools like KlipperScreen or Cartographer - may find it essential for tasks like testing beta features. Actually, the installation of Cartographer, just to give an example for many more modifications, requires to shell just for cloning into git. I would have loved to do this with Moonraker only. These activities aren’t limited to developers alone. However, I accept the situation as it is and will find a way to work around it.

Thank you again for your detailed response.