[bitbake-devel] [PATCH 2/8] git-make-shallow: add script to make a git repo shallow

[Christopher Larson]

On Fri, Jun 2, 2017 at 3:07 AM, Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> Sorry about the delay in getting to this. In general the series looks
> great.
>

Thanks for taking the time to review this, I appreciate it. I know you have
a lot on your plate, and anything invasive in the fetcher is risky and not
particularly fun.


> One minor thing that bothers me a bit is the name of this
> script. If git itself ever creates something similar it may cause us
> issues. I wondered if we wanted to namespace this more closely to
> bitbake?
>
> I'm leaning towards merging this and then perhaps tweaking the naming.
>

That would be fine with me, I’m not particularly attached to the name. I
only  named it this way because it’s of use outside of bitbake as well, but
I can see your namespace concern.

The other thing I'd really like to see is the documentation collected
> out the commit messages and sent to Scott Rifenbark (cc'd) as a summary
> of the changes so he can update the manual, particularly the section on
> the git fetcher. If you could review it once Scott has done that, that
> would be awesome :).
>

I can do that. I might still have a more monolithic description in one of
the previous branches, I only broke it up this way to ease review and
reduce confusion.

I do have my worries about how much complexity this adds to the git
> fetcher but I guess its inevitable and at least we have the tests
> (thanks!).
>

Believe me, I have the same concerns. The fetcher is quite complex as it
is, but I don’t see any other way to solve this particular issue,
unfortunately. I split out git-make-shallow for this reason, to try to pare
down the changes to the fetcher itself, though of course that just
relocates the complexity rather than removing it :) I’d love to hear any
ideas on how to simplify things, or solve this in a different way, as
unfortunately I’m completely out of ideas. I do think this solves a problem
that we should solve, though.

In the back of my mind there is another way I've been wondering about
> assisting fetches, namely a "common reference repo" which urls may name
> (e.g. git://xxx;refrepo=linux-kernel). If this was specified, any clone
> would happen into the reference name as a subset namespace before a
> clone by reference into the main repo name. With kernels, this would
> mean one core repo and then all the subset kernels would clone by
> reference from it. That should mean all kernels would share a common
> repo so once you have one things should all be fast. Obviously shallow
> clones solve a different problem in some ways but there is overlap.
>

I like that idea as an additional improvement. As you say, similar but
slightly different, as shallow helps reduce what sources need to be shipped
/ distributed on and downloaded from a mirror, whereas refrepo is more
about reducing duplication amongst multiple recipes.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/bitbake-devel/attachments/20170602/eee02613/attachment-0002.html>