On Tue, Aug 9, 2016 at 7:24 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: > > On 09.08.2016 18:22, Erik Faye-Lund wrote: >> >> On Tue, Aug 9, 2016 at 4:59 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: >>> >>> On 09.08.2016 15:58, Rob Clark wrote: >>>> >>>> >>>> tbh, git submodules are more annoying than they need to be, and I'm >>>> not really terribly excited to use that for something that is a build >>>> dependency. Maybe just move it into libdrm instead? >>> >>> >>> >>> I know. That's what I would have proposed if the addrlib interface were >>> stable. Unfortunately it isn't, and realistically speaking, that's not >>> going >>> to change. >>> >>> So shared linking is right out. >>> >>> Static linking or just including source files from a separate repository >>> could be considered, but then what's the process for ensuring you have >>> the >>> right version? >>> >>> The nice aspect of submodules is that every commit of the Mesa repository >>> "knows" what the corresponding right version of addrlib is, and so git >>> can >>> update the submodule to the correct version for you automatically. >> >> >> I'm not a huge fan of submodules either. They just don't deal with >> distributed development properly, which should be a non-starter for >> OSS IMO. You either set the submodule to point to an absolute URL, in >> which case it's awkward to work with if you need to change the code, >> or you use a relative URL, which forces everyone who has a fork to >> fork the submodule also. Yuck. As a formerly active Git developer, my >> impression is that nobody of the core-git developers really loved the >> idea of git-submodule, it was mostly introduced into Git to help KDE >> transition their gigantic SVN-external based source tree to Git. >> >> IMO, a much better alternative would be to have addrlib live in its >> own repository, and periodically do a git subtree-merge into mesa and >> other dependent system. That means that nobody really needs to deal >> with the fact that the upstream is in a different repo, except when >> submitting patches for upstream. This is what git.git itself does for >> some of its subsystems. > > > That looks interesting. Are people using subtree-merge with the kind of > linear history that Mesa uses? >
I work mostly with branch-heavy work-flows these days, so I don't really know. The subtree-merges themselves will obviously appear as merges, but you can always keep the development in the upstream linear if you want... _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
