Open sgibson91 opened 2 years ago
It seems allowing unrelated commit histories could make the trick?
--allow-unrelated-histories
We definitely need a good story here for downstream fixes... related discussion https://github.com/2i2c-org/infrastructure/issues/1145#issuecomment-1088031412
I think we should move docs elsewhere to a more centralized place and link to it. Pushing git changes out is unsustainable especially if communities make downstream changes.
@yuvipanda what about changes to workflow files?
Good question! So I think we can separate the contents of this repo into three parts:
We'd definitely have to write some automation scripts to deal with (2) and (3), but I don't know exactly how they'll look until we first do them. I think git merge
is probably going to be too complicated given there are probably unrelated downstream changes, so I'd suggest our automation script is more specific and uses either diff
and am
directly.
Given that we've had to do #10, I think a plan of action is to:
I think this can become a bit of a deep hole with diminishing returns, so I want us to be slightly careful :)
As a proof of concept for what I mean by diff
and am
,
curl -L https://github.com/2i2c-org/hub-user-image-template/pull/13.patch | git am
. Note the .patch
appended to the PR URL - it provides a patch
file that can be applied using git am
. This is one of the many steps git merge
does internally, but git
exposes all this to us too. This lets us apply only specific PRs to a bunch of repos without having to worry about merge histories. Regular conflict resolution can be performed when the patch doesn't apply cleanlyThis would let us port a set of changes across repos without having to deal with all the extra bits that git merge
does.
I really like this proposal!
I really like this proposal!
Indeed! I have successfully used this patch-based approach in the past 😉.
For step 2, are you envisioning some action in the child repo that triggers based on detected changes in the parent repo and do all the curl and git am dance... and finally opens a PR (potentially including automerge)?
I had another thought on this. With regards to the workflow files themselves, we could transform them into reusable workflows such that everyone downstream would benefit from updates, while allowing us to centrally manage them.
Context
This is a template repo that many of our communities use to self-serve images for their hubs. We often make changes and improvements to this template, e.g., #10. But it's not clear to me how we push those improvements to the repositories already using this template.
Since this is a template repo, not a fork, trying to pull changes from this repo into a downstream repo in the "usual" way (say, by adding this repo as a template and running
git fetch --all && git merge...
) will result in atrying to merge unrelated commit histories
error.Proposal
No response
Updates and actions
No response