From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC PATCH] download/git: ban branch references
Date: Sat, 22 Jun 2019 09:47:13 +0200 [thread overview]
Message-ID: <20190622074713.GB13664@scaer> (raw)
In-Reply-To: <20190621173653.3e3c2d89@donbot>
John, All,
On 2019-06-21 17:36 +0100, John Keeping spake thusly:
> We can then filter out non-tags with:
> case $(git rev-parse --symbolic-full-name "${cset}") in
Need for 2>/dev/null or there is a big warning printed (see below).
> refs/tags/*
> : ok
> ;;
> refs/*
> printf >&2 "Refusing to use Git branch '%s'.\n" "${cset}"
> ;;
> # Anything else is not a ref, must be a raw hash which is ok.
That's wrong, because branches may pre-exist from git-clones that we do
currently.
For example, I have a local git clone of linux-firmware, which has:
$ git branch
* 1baa34868b2c0a004dc595b20678145e3fff83e7
44d4fca9922a252a0bd81f6307bcc072a78da54a
d87753369b82c5f362250c197d04a1e1ef5bf698
$ git rev-parse --symbolic-full-name 1baa34868b2c0a004dc595b20678145e3fff83e7
warning: refname '1baa34868b2c0a004dc595b20678145e3fff83e7' is ambiguous.
Git normally never creates a ref that ends with 40 hex characters
because it will be ignored when you just specify 40-hex. These refs
may be created by mistake. For example,
git checkout -b $br $(git rev-parse ...)
where "$br" is somehow empty and a 40-hex ref is created. Please
examine these refs and maybe delete them. Turn this message off by
running "git config advice.objectNameWarning false"
refs/heads/1baa34868b2c0a004dc595b20678145e3fff83e7
$ git rev-parse --symbolic-full-name 1baa34868b2c0a004dc595b20678145e3fff83e7 2>/dev/null
refs/heads/1baa34868b2c0a004dc595b20678145e3fff83e7
So, 1baa34868b2c0a004dc595b20678145e3fff83e7 is the sha1 we curently use
in Buildroot, the two others we used in the past.
So, your code snippet above woud break the build. We have a single
option, really, which is to try and remove the local branch before
checking if the cset is a branch.
So, my position is that the plan stays basically the same:
- get rid of special refs. As I already explained, we already have a
mechanism to catter for that use-case: override-srcdir;
- remove local branches;
- refuse branches.
Regards,
Yann E. MORIN.
> esac
>
> What do you think?
>
>
> Regards,
> John
>
>
> [1] http://buildroot-busybox.2317881.n4.nabble.com/PATCH-0-3-download-detect-and-refuse-git-branch-by-name-td200050.html
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2019-06-22 7:47 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 [this message]
2019-06-24 11:30 ` John Keeping
2019-06-24 11:32 ` [Buildroot] [PATCH v2 1/2] download/git: fetch all refs from the remote John Keeping
2019-06-24 11:32 ` [Buildroot] [PATCH v2 2/2] download/git: ban branch references 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=20190622074713.GB13664@scaer \
--to=yann.morin.1998@free.fr \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.