From: Ricardo Martincoski <ricardo.martincoski@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 4/4] download/git: always do full-clone
Date: Wed, 18 Apr 2018 00:18:01 -0300 [thread overview]
Message-ID: <5ad6b8e98be61_23c23fb7eb3480a4191b4@ultri4.mail> (raw)
In-Reply-To: 62d815cfe104e4d172ca4d51e1d56e577f737b87.1523983687.git.yann.morin.1998@free.fr
Hello,
We can ask for more opinions if it needs to be split in 2 patches or not, so I
copied the CC from patch 3.
Also some typos and nits.
On Tue, Apr 17, 2018 at 01:48 PM, Yann E. MORIN wrote:
> We currently attempt a shallow clone, as tentative to save bandwidth and
> download time.
>
> However, now that we keep the git tree as a cache, it may happen that we
> need to checkout an earlier commit, and that would not be present with a
> shallow clone.
>
> Furthermore, the shallow fetch is already really btroken, and just
s/btroken/broken/
> happens by chance. Consider the following actions, which are basivcally
s/basivcally/basically/
[snip]
> The checkout succeeds just because of the git-fetch in the if-condition,
> which is initially there to fetch the special refs from github MRs, or
Nit: mixed naming
GitHub -> PR
GitLab -> MR
Gerrit -> Change
> gerrit reviews. That fails, but we jsut print a warning. If we were to
s/jsut/just/
> ever remove support for special refs, then the checkout would fail.
>
> The whole purpose of the git cache is to actually save bandwith and
s/bandwith/bandwidth/
> download time, but in the long run. For one-offs, people would
> preferably use a wget download (e.g. with the github macro) instead of
> a git clone.
>
> We switch to always doing a full clone. It is nore correct, and pays off
s/nore/more/
Nit: Actually using shallow fetch is not less correct, just more complicated
because it has a lot of corner cases. But the download script becomes more
correct than before by always doing a full clone.
> in the long run...
[snip]
> +printf "Fetching all references\n"
> +_git fetch origin
The line above could even be a separate patch.
It is there to fix the fetch for all refs for git versions older than 1.9.0.
Maybe we add a comment about the git version?
And/or mention the git version + upstream patch on the commit log, as in
http://patchwork.ozlabs.org/patch/897559/ ?
> +_git fetch origin -t
Regards,
Ricardo
next prev parent reply other threads:[~2018-04-18 3:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-17 16:48 [Buildroot] [PATCH 0/4] support/download: make the git backend more robust Yann E. MORIN
2018-04-17 16:48 ` [Buildroot] [PATCH 1/4] download/git: ensure we always work in the expected repository Yann E. MORIN
2018-04-19 15:47 ` Ricardo Martincoski
2018-04-19 20:38 ` Thomas Petazzoni
2018-04-17 16:48 ` [Buildroot] [PATCH 2/4] download/git: ensure we have a sane repository Yann E. MORIN
2018-04-19 15:50 ` Ricardo Martincoski
2018-04-19 19:45 ` Yann E. MORIN
2018-04-19 20:38 ` Thomas Petazzoni
2018-04-17 16:48 ` [Buildroot] [PATCH 3/4] download/git: ensure we can checkout repos with submodule conversions Yann E. MORIN
2018-04-18 3:13 ` Ricardo Martincoski
2018-04-18 8:04 ` Arnout Vandecappelle
2018-04-19 0:59 ` Ricardo Martincoski
2018-04-19 19:59 ` Yann E. MORIN
2018-04-19 23:30 ` Arnout Vandecappelle
2018-04-20 9:25 ` Yann E. MORIN
2018-04-17 16:48 ` [Buildroot] [PATCH 4/4] download/git: always do full-clone Yann E. MORIN
2018-04-18 3:18 ` Ricardo Martincoski [this message]
2018-04-18 8:40 ` [Buildroot] [PATCH 0/4] support/download: make the git backend more robust Thomas Petazzoni
2018-04-18 8:52 ` Thomas Petazzoni
2018-04-18 13:28 ` Ricardo Martincoski
2018-04-18 14:43 ` Thomas Petazzoni
2018-04-18 21:35 ` Ricardo Martincoski
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=5ad6b8e98be61_23c23fb7eb3480a4191b4@ultri4.mail \
--to=ricardo.martincoski@gmail.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 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.