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 2/3] download/git: recover dirty cache
Date: Tue, 17 Apr 2018 12:36:23 +0200	[thread overview]
Message-ID: <20180417103623.GA8142@scaer> (raw)
In-Reply-To: <5ad5b6a275994_553a2b0a2f22df301567e@ultri4.mail>

Ricardo, Arnout, All,

On 2018-04-17 05:56 -0300, Ricardo Martincoski spake thusly:
> On Tue, Apr 17, 2018 at 05:10 AM, Arnout Vandecappelle wrote:
> > On 17-04-18 09:04, Ricardo Martincoski wrote:
> >> Here is a squashed, no commit log, no comments on the code, hackish preview:
> >> https://gitlab.com/RicardoMartincoski/buildroot/commit/f4e20bb62b761bb6c82a29acbd2f8d56d90e4e9c

ACK. I'll vampirise the git-init part, then.

> >  Looks good to me, with the following mods:
> > 
> > * use GIT_DIR
> > * add comment above git init explaining that it is safe
> > * explain why -ff is needed for git clean

ACK ?3

> > * Removing the shallow fetch should be done in a separate patch (I'm not
> > entirely convinced yet that it is needed).

IIRC, Ricardo explained the case in a previous message: there are cases
where we may miss blobs in a tree.

But anyway, the current code only works by chance. Let's assume you want
to use tag v4.17-rc1 from Linus' tree. The code would currently do
something like (without an existing git cache)

    mkdir git
    git init git
    cd git
    git remote add origin https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
    git fetch origin --depth 1 v4.17-rc1
    if ! git fetch origin v4.17-rc1:v4.17-rc1 ; then
        echo "warning"
    fi
    git checkout v4.17-rc1

The if-block is initially there to fetch special refs created by things
like gerrit or github PRs. If you do the above, you get the warning,
i.e. the if-condition is false, i.e. fetching the tag that way fails
with exit-code 1, and this message:

    error: cannot update the ref 'refs/heads/v4.17-rc1': Trying to write
    non-commit object a79c33a10ce2764c62fb8af6cbb571752d55c1c0 to branch
    refs/heads/v4.17-rc1
    From https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
     ! [new tag]         v4.17-rc1  -> v4.17-rc1  (unable to update local ref)
     * [new tag]         v4.17-rc1  -> v4.17-rc1

But since it is in a if-ciondition, we just print a warning, and
continue.

Then and the checkout succeeds.

But! If you didn't try to fetch the special refs, the checkout would
have failed:

    error: pathspec 'v4.17-rc1' did not match any file(s) known to git.

I.e. we have code that just happens to work by chance (or rather, by
side-effects and luck).

So, even if the missing-blob problem could be solved another way, our
shallow fetch is anyway already borked, but we were lucky so far not to
fall for it...

I still think that this shalow-fetch dance is too risky, and that having
a sane git cache helps so much more in the long run, so much so that we
should just ditch the shallow fetch support.

> These 2 are already covered by Yann's WIP series, with comments and proper
> commit logs:
> https://git.buildroot.org/~ymorin/git/buildroot/log/?h=yem/git-robust

With the last two to be swapped.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2018-04-17 10:36 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12  9:28 [Buildroot] [RFC PATCH 0/3] fix some corner cases for download/git v1 Ricardo Martincoski
2018-04-12  9:28 ` [Buildroot] [RFC PATCH 1/3] download/git: fix fetch all refs for old git Ricardo Martincoski
2018-04-12 17:42   ` Yann E. MORIN
2018-04-13 18:23     ` Ricardo Martincoski
2018-04-15 12:12       ` Yann E. MORIN
2018-04-16  2:17         ` Ricardo Martincoski
2018-04-12  9:28 ` [Buildroot] [RFC PATCH 2/3] download/git: recover dirty cache Ricardo Martincoski
2018-04-12 17:48   ` Yann E. MORIN
2018-04-13 18:28     ` Ricardo Martincoski
2018-04-15 12:02       ` Yann E. MORIN
2018-04-16  2:54         ` Ricardo Martincoski
2018-04-16 16:01           ` Yann E. MORIN
2018-04-16 20:56             ` Yann E. MORIN
     [not found]               ` <1ffe206e-4b1e-c233-a511-ba4c3a8cb5f0@armadeus.com>
2018-04-17 10:42                 ` Yann E. MORIN
2018-04-17 11:30                   ` Thomas Petazzoni
2018-04-17  4:45             ` Ricardo Martincoski
2018-04-17  7:04               ` Ricardo Martincoski
2018-04-17  8:10                 ` Arnout Vandecappelle
2018-04-17  8:56                   ` Ricardo Martincoski
2018-04-17 10:36                     ` Yann E. MORIN [this message]
2018-04-17 11:58                       ` Arnout Vandecappelle
2018-04-12  9:28 ` [Buildroot] [RFC PATCH 3/3] download/git: unshallow when fetching all refs Ricardo Martincoski
2018-04-12 11:28   ` Thomas Petazzoni
2018-04-12 17:33     ` Yann E. MORIN
2018-04-13 18:32       ` Ricardo Martincoski
2018-04-15 12:08         ` Yann E. MORIN
2018-04-16  3:04           ` 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=20180417103623.GA8142@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.