Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] autobuild-run: remove only tarballs from download dir
Date: Sun, 15 Apr 2018 22:10:26 +0200	[thread overview]
Message-ID: <20180415201026.GA13321@scaer> (raw)
In-Reply-To: <20180415220222.6413547a@windsurf.numericable.fr>

Thomas, All,

On 2018-04-15 22:02 +0200, Thomas Petazzoni spake thusly:
> On Sun, 15 Apr 2018 21:49:15 +0200, Yann E. MORIN wrote:
> > > Just to check how this is supposed to work. We have this:
> > > 
> > >  dl/<package>/git/.git
> > > 
> > > Correct ?
> > > 
> > > So you're idea is that when we are inside dl/<package>/git/, one of the
> > > sub-directories is .git, and therefore we shouldn't remove anything in
> > > dl/<package>/git/ ?
> > > 
> > > My concern is that I'm not sure if what you've done prevents from
> > > removing files inside dl/<package>/git or only inside
> > > dl/<package>/git/.git. I would find it more to do something like:
> > > 
> > > 	if "git" in d:
> > > 		d.remove("git")
> > > 
> > > but perhaps you haven't done this for some good reason ?
> > > 
> > > Another concern is how to fix those autobuilders that have already
> > > removed some random files from their cached Git repositories? Should we
> > > ask the people who run those autobuilders to entirely wipe the download
> > > folders of their autobuilder instances ? Or do we have a smart (but
> > > simple) thing to do to avoid this ?  
> > 
> > For this last part, we've already discused this with Ricardo in another
> > thread: we run git-fsck, and if there is an error, we ditch the git tree
> > and clone from scratch.
> 
> OK, so in practice removing random files inside the git/ folders should
> not cause any problem ?

Well, if you remove files from the working copy, no. The next git-checkout
would fix it to a certain extent, which can be covered by a mix of
git-clean + git-checkout, again to a certain extent...

However, if you remove files from below .git, you can cause heavy
breakage. Even removing a single object will cause the tree to get
uterly broken, not telling what happens when one removes a ref or
HEAD.

So, runniong git-fsck would catch the cases where something is missing
in .git, in which case we're toast and the git cache is as good as if
it were not present.

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-15 20:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-13 13:34 [Buildroot] [PATCH] autobuild-run: remove only tarballs from download dir Ricardo Martincoski
2018-04-15 19:42 ` Thomas Petazzoni
2018-04-15 19:49   ` Yann E. MORIN
2018-04-15 20:02     ` Thomas Petazzoni
2018-04-15 20:10       ` Yann E. MORIN [this message]
2018-04-15 20:38         ` Thomas Petazzoni
2018-04-15 20:59           ` Yann E. MORIN
2018-04-15 23:18     ` Ricardo Martincoski
2018-04-15 22:23   ` Ricardo Martincoski
2018-04-16  9:01     ` Yann E. MORIN
2018-04-16 16:05     ` Thomas Petazzoni
2018-04-16 16:09 ` Thomas Petazzoni
2018-04-17  4:38   ` Ricardo Martincoski
2018-04-17  7:12 ` [Buildroot] [PATCH v2] " Ricardo Martincoski
2018-04-19 21:39   ` Thomas Petazzoni

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=20180415201026.GA13321@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox