[freedomben]

Unrelated but about Brave and interesting to me: I recently found myself having a large upstream project that I need to maintain some custom patches for, and there's a need for deeper customizations and I worry that my rudimentary system of applying .patch files will turn into an unmaintainable nightmare of merge conflicts after every rebase. I was thinking about possible solutions, and it occurred to me that Brave being Chromium-based must have this same challenge but an order of magnitude more difficult, so I looked for their code to see how they solved this issue.

It's pretty interesting! They do basically the same thing for core Chromium, applying a (big) set of patches[1].

Incidentally, I'd be interested to hear any ideas/approaches to this problem. I'm guessing if there was something clearly better, Brave would be doing it, but it seems like there should be a better way even if I can't think of one.

[1] https://github.com/brave/brave-core/tree/master/patches

[bsclifton]

Something I would like to mention, as a dev on Brave, is that patches are considered a last resort. If there are patches, we try to keep them lightweight - like patch to have Chromium create the Brave version of the object (something we can restrict to one line).

What you'll notice more often is a folder we have called `chromium_src`. This directory mirrors the directory structure for Chromium under `src` and the build system will look for matches. If there's a file with the same name under `chromium_src`, it'll prefer that one. That file then does what it needs to differently and then includes the original file.

This approach helps keep things much more lightweight - but it has challenges too. If code fails to apply (file that `chromium_src` is matching gets renamed, etc) it can be hard to detect. This is where you'd want to have a test to catch that.

Another person shared - but here's a link to our patching documentation: https://github.com/brave/brave-browser/wiki/Patching-Chromiu...

You'll notice the actual patching itself is introduced with the caveat:

  > When other options are exhausted, you can patch the code directly

[freedomben]

Thank you! I really appreciate the info :-)

[SushiHippie]

I don't know why they went with patch files instead of forking chromium and rebasing the changes via git.

They document how developers should "rebase" chromium:

https://github.com/brave/brave-browser/wiki/Chromium-rebases...

And it looks like way more work than doing it with git via

  git rebase chromium/master

[fabrice_d]

If you do that kind of rebase you have to force-push to your branch, and that's not great for many reasons. The other option is to `git merge chromium/master` into your fork. This way you don't have to force-push, but the history is not that clean and bisecting can be tricky.

[SushiHippie]

Ah true didn't think of that, as I've never worked on such large projects were force pushing becomes a problem.

But with manually editing .patch files you need to manually find out how to resolve the conflicts, while in a rebase git at least shows you the merge conflicts.

[zilti]

Because `git rebase` is a heap of crap