All of lore.kernel.org
 help / color / mirror / Atom feed
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.  |
'------------------------------^-------^------------------^--------------------'

  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.