<html>#2965: GetComponents option to obtain new branch
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Jordan Nicoules</td></tr>
<tr><td style='text-align:right'> Status:</td><td>new</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'> Version:</td><td></td></tr>
<tr><td style='text-align:right'> Type:</td><td>enhancement</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>minor</td></tr>
<tr><td style='text-align:right'>Component:</td><td>GetComponents</td></tr>
</table>
<h2 id="markdown-header-context">Context</h2>
<p>Typically on a new release, calling <code>GetComponents</code>, even with the update option, will check out new components, but existing ones will not deal with the <code>!REPO_BRANCH = $ET_RELEASE</code> 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 <code>Carpet</code> and <code>POWER</code>, between ET_2023_05 and ET_2026_05).</p>
<p>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.</p>
<h2 id="markdown-header-suggested-feature-details-tbd">Suggested feature (details TBD)</h2>
<p><strong>Either with the update option or a new option, add the <code>!REPO_BRANCH</code> to the fetch list, create the corresponding branch, and check it out if possible.</strong>
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.</p>
<p>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.</p>
<h2 id="markdown-header-discussion">Discussion</h2>
<ol>
<li>Is this feature desirable? Does it correspond better to a user's expectation?</li>
<li>Can it be harmful?</li>
<li>Does it actually save work and effort, compared to recreating a brand new Cactus directory? </li>
</ol>
<p>About point 2, a conservative addition of a fetched ref and corresponding local branch, even if not checked out, looks benign to me.</p>
<p>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
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2965/getcomponents-option-to-obtain-new-branch'>https://bitbucket.org/einsteintoolkit/tickets/issues/2965/getcomponents-option-to-obtain-new-branch</a></p>
</html>