Merging upstream? (2026-07)

[illwieckz]

So I'm proposing doing a new round of merging from upstream, to reach current status of Google breakpad.
This for examples add support for more architectures and globally they likely not just moved things around.

We have two options:

• Merging them over us, to keep the upstream commit history and our commit history.
• Rebasing us over them, to also keep the upstream commit history but rewriting our commit history with a linear history.

If we rebase us over them, it's not a big problem, that's what we did the last time, and our previous branch ended into the legacy/unvanquished-0.51 branch.

If we merge them over us, here is a working branch:

• illwieckz/rebase-main-9aebd3d

This is a temporary branch rebasing them over us, which is not meant to be merged in anyway. But it's easier to solve git conflicts by solving them commits per commits one by one through a rebase than solving all git conflicts at once while merging. The idea is that once everything is fixed, then we can just do the merge of them over us and solve the merge conflicts by blindly copying verbatim the fixed rebase branch content and commit that in the merge commit.

What is remaining to do with the rebase branch is to check those commits for which the conflict solving are to be verified or finished:

• Restructure Makefile conditionals/targets
  • This conflicted with the MinGW stuff and the change building against system curl
• gyp: drop unused build system
  • This dropped gyp but the MinGW build used it for dump_syms_dwarf, see this comment in Makefile.am:
    # For MinGW, use gyp to generate a Makefile to build Windows client library
• Fix inline_origin_map key collision when split dwarf is enabled.
  • It rewrote a code where our branch introduced some DWPREADER_WANTED ifdef.
• enable git submodules support
  • It conflicted with our “Hard commit lss again” commit,
    right now the rebase use the introduced submodule, we may decide to do it that way.
  • As a side note the # src/third_party/lss line in .gitignore conflicted many time while rebasing,
    but if we do the merge and copy the result we don't have to care about the temporary rebase history of it.

The rest of the merge conflicts looked somewhat straightforward, especially most of the conflict where just us having deleted temporary autoconf generated leftover files the Google developer insist to commit every now and then.

The Restructure Makefile conditionals/targets commit was the most conflicting one, it's not surprised given the name.

And of course, we should check that the tools still build and run properly.

[illwieckz]

Google developers have a very bad habit to store random compiled binaries into their repos like this madness.

Fortunarly the binaries are not crazily big:

$ du -shc src/tools/windows/binaries/*.exe
540K	src/tools/windows/binaries/dump_syms.exe
668K	src/tools/windows/binaries/symupload.exe
1,2M	total

So we may not care, or we rebase on their branch but cleaned-up (like we did with the NaCl runtime).

It should be noted that those binaries are actually committed in their branch but ignored by our *.exe rule in .gitignore.
I still don't get why they do follow such very bad practices.

Whatever the merge strategy we use, even if we keep those file in history, we should delete those binaries from our own tree after the merge succeeded. No one should ever use them. No one knows who build them neither how they have been built, they were just stored there the most suspiciously “trust me bro” way, and they are obsolete by definition.

[illwieckz]

I can also do a temporary branch rebasing us over them if that's preferred.

[slipher]

Maybe rebasing over upstream would be too messy now since we already have past merge conflicts? I mean with the DWARF5 x MinGW stuff. Let's go with a merge.

• gyp: drop unused build system

  • This dropped gyp but the MinGW build used it for dump_syms_dwarf, see this comment in Makefile.am:
    # For MinGW, use gyp to generate a Makefile to build Windows client library

That's annoying. I guess upstream migrated to "GN" or whatever? Surely no one outside of Chrome is interested in using this. But not so much GYP either. Really the important thing here is just to have a list of files that need to go in each library... maybe just leave the last version of GYP there?

• enable git submodules support

  • It conflicted with our “Hard commit lss again” commit,
    right now the rebase use the introduced submodule, we may decide to do it that way.
  • As a side note the # src/third_party/lss line in .gitignore conflicted many time while rebasing,
    but if we do the merge and copy the result we don't have to care about the temporary rebase history of it.

I want to avoid multiple levels of submodules beyond {Unvanquished,Daemon}/libs. So just commit the lss file contents again.

[illwieckz]

Maybe rebasing over upstream would be too messy now since we already have past merge conflicts?

The biggest merge conflict was Makefile.am. Since we rebased the other time, we fixed most of them. So fixing merge conflict by rebasing A over B or B over A is basically the same cost.

maybe just leave the last version of GYP there?

Ah yes, maybe that will just work.

I want to avoid multiple levels of submodules beyond {Unvanquished,Daemon}/libs. So just commit the lss file contents again.

Right.

The good thing about us rebasing over them from time to time is that it keeps our patches cleanly identifiable atop them. Also the LSS and GYP stuff would just be small partial revert commits. But then, maybe some have started using our Breakpad because our Breakpad is cool (I remember some Godot guy talking about it if I'm right).

And in fact, i forgot about it, but actually the last time we merged, not rebased:

• Merge Google upstream to get DWARF5 support #16

So let's do it the merge way. Right, so the best way to achieve that is to start adding some patches above my temporary rebase branch to fix all the issues we find, and when we are ready, we do a merge and use the validated repo content from the rebase branch as merge commit.