On 01/11/2024 12:26 pm, Jason Andryuk wrote:
> On 2024-10-31 18:52, Andrew Cooper wrote:
>> 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 <andrew.coop...@citrix.com>
>>>>> ---
>>>>> CC: Jan Beulich <jbeul...@suse.com>
>>>>> CC: Stefano Stabellini <sstabell...@kernel.org>
>>>>> CC: Julien Grall <jul...@xen.org>
>>>>>
>>>>> 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...
>
> I'm not clear on the exact problem
These were the failure following the original patch, which lead to this
patch.
https://gitlab.com/xen-project/hardware/xen/-/pipelines/1521590040
and https://gitlab.com/xen-project/hardware/xen/-/jobs/8237236030#L267
is one specific instance
> , but can you just checkout the FETCH_HEAD:
>
> $GIT fetch origin $TAG
> $GIT branch -D dummy >/dev/null 2>&1 ||:
> $GIT checkout -b dummy FETCH_HEAD
Hmm yeah, that looks like it might work. Thanks. I'll have a play.
~Andrew
