[Buildroot] [PATCH] support/download: fetch all refs on full git clone

Vivien Didelot vivien.didelot at savoirfairelinux.com
Fri Nov 13 15:35:59 UTC 2015


Hi Arnout,

On Nov. Friday 13 (46) 07:49 AM, Arnout Vandecappelle wrote:
> On 12-11-15 18:07, Vivien Didelot wrote:
> [snip]
> > This is orthogonal, but I'm wondering if it'd make sense to stamp a git
> > remote update, similary to the local kernel setup + rsync. That would
> > ease the build process of a team, when a parallel kernel development is
> > on going.
> 
>  I'm not sure what you mean with stamping a git remote update. What I think
> would make sense is that for distributed VCS downloads (i.e. git and hg) we keep
> a full (shallow) clone in DL_DIR in addition to the tarball. That makes handling
> updates a lot more efficient. We probably would want to expose that to PRIMARY
> and SECONDARY download sites as well. Especially the PRIMARY would be useful,
> since it would allow you to start from a local clone of e.g. linux.git (which
> may not have the ref you need), and then just fetch the missing refs from upstream.
> 
>  This will not be easy to implement, though, since we'd need to handle e.g.
> multiple remotes that end up in the same DL_DIR/foo.git repository.
> 
> 
>  Was this what you meant, Vivien?

What I meant is, when you use BR2_LINUX_KERNEL_CUSTOM_LOCAL, Buildroot will 
stamp a .stamp_rsynced file and re-sync on later `make linux-rebuild`. This is 
really handy.

I don't think pointing to a Git repository is much different from this 
(especially during the development phase). Similary to rsync, `git remote 
update` can be used to sync a mirror clone (says the git-clone man page).

I'm thinking that we may either rework a generic $(1)-sync target which handles 
both rsync and `git remote update`, or introduce a $(1)-update target?

Caching full mirror clones is indeed the way to go. Several defconfig use the 
same Git repository. (e.g. 7 use linux-at91 and 7 use linux-2.6-imx). We need 
a clone to have a non-git identifier. I'd suggest to hash 
BR2_LINUX_KERNEL_CUSTOM_REPO_URL. sha1sum would give us the following paths:

"git://git.freescale.com/imx/linux-2.6-imx.git" # => linux-36a3f7006936f66cbf83b1de5bd179b2e72ceb4b.git
"https://github.com/linux4sam/linux-at91.git" # => linux-75076bea97e59045a5cfc8d84078976952d751bf.git

We might not want to store the clones in the same directory as the 
ready-to-be-extracted sources, so maybe a DL_VCS_DIR can be introduced.

Thanks,
-v



More information about the buildroot mailing list