Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: John Keeping <john@metanate.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 1/2] download/git: fetch all refs from the remote
Date: Mon, 24 Jun 2019 12:32:23 +0100	[thread overview]
Message-ID: <20190624113224.22685-1-john@metanate.com> (raw)
In-Reply-To: <20190624123027.485c128f@donbot>

Instead of fetching branches and tags then following up with another
request in case the specified version is a special branch like a pull
request, simply mirror the remote repository and fetch all of its refs.

This allows using a raw commit hash pointing to anything reachable on
the remote (for example a commit in a pull request which is not yet in a
branch), even if the server has not set allowReachableSHA1InWant.

There is one subtlety to this which is that Git will not let us update
the ref of a branch which is checked out.  Ideally we would just detach
HEAD to bypass this problem, but that doesn't work in an empty
repository when we are on an unborn branch.  Instead, we create an
unborn branch of our own pointing to a ref which is very unlikely to
exist.

Signed-off-by: John Keeping <john@metanate.com>
---
 support/download/git | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/support/download/git b/support/download/git
index 075f665bbf..02bf01bb95 100755
--- a/support/download/git
+++ b/support/download/git
@@ -111,20 +111,19 @@ fi
 
 _git remote set-url origin "'${uri}'"
 
+# We will use an explicit refspec, so we don't want any automatic
+# mapping from Git. This will fail if the key doesn't exist and we don't
+# want to delete the repository in that case so we ignore errors from
+# this command.
+_git config --unset-all remote.origin.fetch || true
+
 printf "Fetching all references\n"
-_git fetch origin
-_git fetch origin -t
-
-# Try to get the special refs exposed by some forges (pull-requests for
-# github, changes for gerrit...). There is no easy way to know whether
-# the cset the user passed us is such a special ref or a tag or a sha1
-# or whatever else. We'll eventually fail at checking out that cset,
-# below, if there is an issue anyway. Since most of the cset we're gonna
-# have to clone are not such special refs, consign the output to oblivion
-# so as not to alarm unsuspecting users, but still trace it as a warning.
-if ! _git fetch origin "'${cset}:${cset}'" >/dev/null 2>&1; then
-    printf "Could not fetch special ref '%s'; assuming it is not special.\n" "${cset}"
-fi
+# We can't update a checked-out branch and if we've just created a new
+# repo there aren't any commits to checkout a detached head, so we point
+# HEAD at a ref which really shouldn't exist, creating a temporary
+# unborn branch.
+_git symbolic-ref HEAD refs/buildroot-invalid-branch
+_git fetch --prune origin +refs/*:refs/*
 
 # Check that the changeset does exist. If it does not, re-cloning from
 # scratch won't help, so we don't want to trash the repository for a
-- 
2.22.0

  reply	other threads:[~2019-06-24 11:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-19 15:18 [Buildroot] [RFC PATCH] download/git: ban branch references John Keeping
2019-06-19 15:34 ` John Keeping
2019-06-20 16:39   ` Yann E. MORIN
2019-06-21 16:36     ` John Keeping
2019-06-22  7:47       ` Yann E. MORIN
2019-06-24 11:30         ` John Keeping
2019-06-24 11:32           ` John Keeping [this message]
2019-06-24 11:32             ` [Buildroot] [PATCH v2 2/2] " John Keeping
2019-12-29 22:12               ` Yann E. MORIN
2020-01-02 17:57                 ` John Keeping
2019-12-29 22:03             ` [Buildroot] [PATCH v2 1/2] download/git: fetch all refs from the remote Yann E. MORIN
2019-06-20 17:27 ` [Buildroot] [RFC PATCH] download/git: ban branch references Joel Carlson
2019-06-21 12:36   ` John Keeping

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190624113224.22685-1-john@metanate.com \
    --to=john@metanate.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox