[Mesa-dev] Moving amdgpu/addrlib into a git submodule

[Erik Faye-Lund]

On Tue, Aug 9, 2016 at 7:24 PM, Nicolai Hähnle <nhaehnle at 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 <nhaehnle at 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...