From: Carlos Santos <casantos@datacom.ind.br>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] core/download: remove support for special git refs
Date: Thu, 27 Oct 2016 08:43:25 -0200 (BRST) [thread overview]
Message-ID: <1879889648.3139938.1477565005989.JavaMail.zimbra@datacom.ind.br> (raw)
In-Reply-To: <20161027091027.6410d400@free-electrons.com>
> From: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
> To: "Vivien Didelot" <vivien.didelot@savoirfairelinux.com>
> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>, "Ricardo Martincoski" <ricardo.martincoski@datacom.ind.br>,
> buildroot at buildroot.org
> Sent: Thursday, October 27, 2016 5:10:27 AM
> Subject: Re: [Buildroot] [PATCH] core/download: remove support for special git refs
> Hello,
>
> On Wed, 26 Oct 2016 18:27:57 -0400, Vivien Didelot wrote:
>
>> > So, just remove the support for such special refs altogether.
>>
>> I don't see why it is hard to maintain. A Github pull request ref or a
>> Gerrit change ref, as well as a custom ref, are valid git references.
>
> They are valid, but moving references, right? A little bit like a
> branch.
>
> And we don't support using Git branches as the Git version. Indeed, if
> you do that, Buildroot will clone the Git repo once, tarball it in
> $(DL_DIR), and will never download it again, because the name of the
> branch doesn't change, so the name of the tarball doesn't change.
>
> And we don't even try to solve this problem, because using a branch
> name as the <pkg>_VERSION is just plain wrong.
As far as I know nobody is asking Buildroot to support branch names in
<pkg>_VERSION.
>> That can totally end up in a customer defconfig.
>
> And this is bogus, and precisely why we don't want to support such
> thing. Github pull request and Gerrit change references are moving, so
> a given Github pull request can one day contain a given version of the
> code, and the next day a different version of the code. Hence you're
> giving your customers something that is not reproducible. Not good.
I'm not sure about Github pull requests but Gerrit change-ids could not
be used in <pkg>_VERSION because they are not valid Git commit-ids.
Each patchset in a Gerrit change has a unique commmit-id, which is not
a moving reference. It be referred to ether by a SHA-1 or by an explicit
path like "refs/changes/70/24070/1". The later is ugly but still unique
and will be saved be saved as
$(DL_DIR)/<pkg>-refs_changes_70_24070_1.tar.gz
Carlos Santos (Casantos)
DATACOM, P&D
next prev parent reply other threads:[~2016-10-27 10:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-26 20:08 [Buildroot] [PATCH] core/download: remove support for special git refs Yann E. MORIN
2016-10-26 22:27 ` Vivien Didelot
2016-10-27 7:10 ` Thomas Petazzoni
2016-10-27 10:43 ` Carlos Santos [this message]
2016-10-27 23:11 ` Arnout Vandecappelle
2016-10-27 0:01 ` Carlos Santos
2016-11-02 19:48 ` Arnout Vandecappelle
2016-11-03 1:01 ` Henrique Marks
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=1879889648.3139938.1477565005989.JavaMail.zimbra@datacom.ind.br \
--to=casantos@datacom.ind.br \
--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.