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

  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.