On 31/10/2024 10:44 pm, Stefano Stabellini wrote:
>
> On Thu, 31 Oct 2024, Andrew Cooper wrote:
>
>> On 31/10/2024 1:47 pm, Andrew Cooper wrote:
>>> The change works for divergent branches, but doesn't work for explicit SHAs.
>>>
>>> Instead of passing `-b $TAG` to clone, explicitly fetch the $TAG we want
>>> after
>>> cloning.
>>>
>>> Fixes: c554ec124b12 ("scripts: Fix git-checkout.sh to work with branches
>>> other than master")
>>> Signed-off-by: Andrew Cooper <[email protected]>
>>> ---
>>> CC: Jan Beulich <[email protected]>
>>> CC: Stefano Stabellini <[email protected]>
>>> CC: Julien Grall <[email protected]>
>>>
>>> Speculative fix, pending CI:
>>> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1521847529
>> Nope. While this works on staging, it breaks on 4.17
>>
>> Back to the drawing board.
>
> I am not certain about this but maybe we need:
>
> $GIT fetch origin
>
> without the $TAG
You need the $TAG to guide what to pull when it's not a parent of master.
For real tags (which live in a global namespace), and real SHAs (don't
need any further reference), creating a branch called `dummy` from them
works fine.
The problem for branches is that $GIT fetch origin $TAG only updates
FETCH_HEAD and doesn't create a remote branch of the same name. You can
do that with $GIT fetch origin $TAG:$TAG but only if you know that $TAG
is really a branch in the first place.
Which circles back around to the original problem of not being able to
disambiguate what $TAG is until you've got the whole repository.
I'm not aware of any way to ask the remote "do you know what type of
object $TAG actually is?" and that's probably because it would be a
reverse lookup through refs/ to figure out if it was a branch or not.
I'm sure there must be a way of doing this...
~Andrew
