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, 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
?
Regards,
Jason
