<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 2, 2017 at 3:07 AM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":ov" class="a3s aXjCH m15c684664ea89bf5">Sorry about the delay in getting to this. In general the series looks<br>
great.</div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":ov" class="a3s aXjCH m15c684664ea89bf5">One minor thing that bothers me a bit is the name of this<br>
script. If git itself ever creates something similar it may cause us<br>
issues. I wondered if we wanted to namespace this more closely to<br>
bitbake?<br>
<br>
I'm leaning towards merging this and then perhaps tweaking the naming.<br></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":ov" class="a3s aXjCH m15c684664ea89bf5">
The other thing I'd really like to see is the documentation collected<br>
out the commit messages and sent to Scott Rifenbark (cc'd) as a summary<br>
of the changes so he can update the manual, particularly the section on<br>
the git fetcher. If you could review it once Scott has done that, that<br>
would be awesome :).<br></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":ov" class="a3s aXjCH m15c684664ea89bf5">
I do have my worries about how much complexity this adds to the git<br>
fetcher but I guess its inevitable and at least we have the tests<br>
(thanks!).<br></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":ov" class="a3s aXjCH m15c684664ea89bf5">
In the back of my mind there is another way I've been wondering about<br>
assisting fetches, namely a "common reference repo" which urls may name<br>
(e.g. git://xxx;refrepo=linux-<wbr>kernel). If this was specified, any clone<br>
would happen into the reference name as a subset namespace before a<br>
clone by reference into the main repo name. With kernels, this would<br>
mean one core repo and then all the subset kernels would clone by<br>
reference from it. That should mean all kernels would share a common<br>
repo so once you have one things should all be fast. Obviously shallow<br>
clones solve a different problem in some ways but there is overlap.</div></blockquote></div><br>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.<br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Christopher Larson<br>kergoth at gmail dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Senior Software Engineer, Mentor Graphics</div></div></div></div>
</div></div>