All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] git fetcher: do not remove the tree after initial clone
Date: Tue, 30 Aug 2011 10:20:20 +0200	[thread overview]
Message-ID: <4E5C9D44.6060704@lucaceresoli.net> (raw)
In-Reply-To: <CALB96N=tS1DKyTgLs8WF6Gh_UYPjWUbiRFGx+FkTauCiDw7OmQ@mail.gmail.com>

Dechesne, Nicolas wrote:
> Lucas, Thomas,
>
> On Mon, Aug 29, 2011 at 2:23 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com
> <mailto:thomas.petazzoni@free-electrons.com>> wrote:
>
>      > Using BR for development has not been completely neglected anyway.
>      > Recently, Thomas Petazzoni submitted a patch that would allow to
>     use a
>      > local directory to build the package. This is much different from
>     using
>      > git fetches, but is expected to serve the "use BR for
>     development" use
>      > case effectively.
>      > You might want to test it and comment to the author. Here it is:
>      > http://lists.busybox.net/pipermail/buildroot/2011-July/044479.html
>
>     I still think that this local directory mechanism is a better solution.
>
>     I have a new version of my patch set, which I hope to submit soon, at
>     least when the 2011.11 development process will open (by the end of the
>     month, so should be in the next few days).
>
>
> i like the 'local directory' method as well, really much. but i still
> believe that the 2 things are complementary..

Thomas' local directory mechanism has an advantage: it works also for
non-git (and even non-versioned) packages.

You could somehow use this method for your needs too: git clone in a
local directory once, then git pull before each BR rebuild. Not as
straightforward as you would like, but maybe a good compromise.

>
> i happen to use BR in a project using large git tree which are not close
> to me, so I care about git fetch vs git clone.
> on top of that there are many users that regularly make rebuild.
>
> the way i see what i propose is *just* an optimization of how BR will
> use git, not a new workflow.

Still it has the disadvantage of using a lot of disk space, and it needs
to connect to the server at every build only to discover if there are
new commits.

This would hurt people not having your needs.

If you would add an option to choose between the always-clone git
downloader and the clone-once-fetch-many version, your work would become
more interesting.
But this is only my opinion.

Luca

  reply	other threads:[~2011-08-30  8:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-28 13:32 [Buildroot] [PATCH] git fetcher: do not remove the tree after initial clone Nicolas Dechesne
2011-08-29  7:48 ` Luca Ceresoli
2011-08-29 12:23   ` Thomas Petazzoni
2011-08-29 14:59     ` Dechesne, Nicolas
2011-08-30  8:20       ` Luca Ceresoli [this message]
2011-08-30  8:43         ` Dechesne, Nicolas

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=4E5C9D44.6060704@lucaceresoli.net \
    --to=luca@lucaceresoli.net \
    --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.