Context

Typically on a new release, calling GetComponents, even with the update option, will check out new components, but existing ones will not deal with the !REPO_BRANCH = $ET_RELEASE which changes in the thornlist. On the other hand, a change in the repo's URL is detected and triggers some error, asking for a clean checkout (at least I could see that for Carpet and POWER, between ET_2023_05 and ET_2026_05).

From a naive user perspective, I expected that updating components with a thornlist that indicates an ET version would put the repos on the corresponding branch, ready to be compiled.

Suggested feature (details TBD)

Either with the update option or a new option, add the !REPO_BRANCH to the fetch list, create the corresponding branch, and check it out if possible. Possibly (as an option), it could also remove the previous one. This makes the most sense for branches that are release versions, but may not in general.

A minima, if there are possible conflicts (unstaged changes etc.), it could raise a warning/error like for the URL, that the user would then deal with manually.

Discussion

1. Is this feature desirable? Does it correspond better to a user's expectation?
2. Can it be harmful?
3. Does it actually save work and effort, compared to recreating a brand new Cactus directory?

About point 2, a conservative addition of a fetched ref and corresponding local branch, even if not checked out, looks benign to me.

Regarding point 3, to me one of the issues is the following. With a new Cactus directory, it's needed to manually move and redo possible local changes and/or additions (tracking more branches/remotes, local commits,...) -- even for forked/owned repositories, although it's less critical in that case. This manual adjustme

--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2965/getcomponents-option-to-obtain-new-branch