[Mesa-dev] [PATCH] amd/addrlib: update to latest version

[Michel Dänzer]

On 08/11/17 10:13 AM, Nicolai Hähnle wrote:
> On 08.11.2017 09:53, Michel Dänzer wrote:
>> On 07/11/17 10:58 PM, Marek Olšák wrote:
>>> On Tue, Nov 7, 2017 at 9:01 PM, Nicolai Hähnle <nhaehnle at gmail.com>
>>> wrote:
>>>> On 07.11.2017 18:35, Michel Dänzer wrote:
>>>>> On 07/11/17 06:28 PM, Marek Olšák wrote:
>>>>>>
>>>>>> I just overwrote all Mesa files with internal addrlib and discarded
>>>>>> hunks that we should probably keep, but I might have missed
>>>>>> something.
>>>>>
>>>>> FWIW, if a separate branch was used for importing addrlib changes, Git
>>>>> could keep track of our changes to it in the Mesa tree.
>>>>
>>>> I concur in principle. In practice, I explored doing that, but the
>>>> commit
>>>> discipline on the internal addrlib repository is pretty crappy, so
>>>> we'd end
>>>> up having to massage commits anyway. Maybe we can find a sweet spot
>>>> somewhere by updating slightly more regularly, perhaps once a month.
>>>
>>> That's too much time-consuming work with no benefit. I used to do
>>> that, but it sucked. I prefer 1 commit with everything - easy conflict
>>> resolution, not having to rebase 60 commits that don't make sense.
>>
>> FWIW, I didn't mean importing individual commits of the addrlib
>> repository into Mesa. Just having a separate branch[0] where addrlib
>> snapshots are imported and which is then merged to master. That way Git
>> will keep track of changes in both repositories and automatically merge
>> them as much as possible. Just using Git for what it was made for. :)
> 
> What do you mean precisely? I did some experiments with a structure like
> this:
> 
>  Mesa master  o--o--o--o--o--o--o
>                       /        /
>  addrlib    o--o--o--o--------o
> 
> where addrlib is a branch that *only* contains addrlib and has a
> completely separate initial commit.

Yeah, that's what I'm thinking of. (Once upon a time, the origin of both
branches would have been connected via the "empty commit" with a hash of
all 0s, but apparently Git stopped using that at some point)


> This works somewhat reasonably, except I was  worried that it might break
> bisecting Mesa by trying some of the commits that only exist in the addrlib
> branch.
> 
> Though now that I think about it again, maybe bisecting is fine because
> none of the addrlib commits are ever in the "future cone" of any Mesa
> master commit.

Hmm, not sure offhand. But even if bisecting can end up on addrlib
branch commits, "git bisect skip" should work fine. If a problem was
caused by changes in the addrlib repository (or a bad merge), bisection
should identify the corresponding addrlib commit and merge commits as
the only candidates.


>> [0] Note that the separate branch doesn't need to exist in any shared
>> repository, it can always be re-created from the history of the last
> merge.
> 
> How would that work? Possibly if we take a note in the addrlib commit
> message what the import source was,

Why would that be necessary? All that should be required is that the
addrlib snapshots use a consistent directory structure.

> but that does seem a bit fragile to me and it would still mean that `git merge'
> can't be used because the history is not represented in the commit graph.

It is represented, as can be seen in your ASCII art graph above. The
addrlib branch can be re-created using the non-master parent commit of
the last merge commit.


Note that because this method hasn't been used so far, we'd first need a
merge with -s ours (keep the tree as it is on the master branch) from an
addrlib branch commit corresponding to the current addrlib snapshot in
master. Any further merges can be done as above.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer