Reputation: 210755
I expect this problem is common, but for the life of me I can't seem to find a good solution:
Project Foo requires third-party project Bar's source (which I have no control over)
Project Foo adds Bar as a submodule, because that's the Git solution to this problem
It turns out Bar requires a handful of tiny patches that will never be merged upstream, as they are quite specific to Foo
I could "commit" patches to Bar inside Foo. This would make sense since these patches are specific to Foo and not applicable to other users of Bar.
It seems I have to either provide a custom script that the user runs every time in order to patch its copy of Bar (a pain and quite fragile), or I have to host (and consistently keep up to date) a custom copy of every single third-party repository I need (also a pain, seems quite an overkill for tiny patches, and seems weird for changes that are specific to Foo).
What solution am I supposed to use for this problem? I imagine it's quite common, yet I get the feeling Git's "solution" is that patches always be merged upstream, which is quite a non-starter.
Upvotes: 4
Views: 1336
Reputation: 1328522
You can, inside Foo/Bar
submodule:
patch
branch, Foo
specific patches to Bar
,patch
branch to that fork Bar
remote.Don't forget to go back in Foo
, add and commit the new Bar
SHA1 (gitlink, special entry in Foo
index) and push Foo
as well.
Now, each time you will update (git fetch) Bar
from its original remote (over which you have no control), rebase your patch
branch over origin/master
of Bar
. (Then, as usual, push Bar
to your Bar
fork, go back in Foo
, add, commit and push)
Upvotes: 1