help wanted (involves git)

[cellio]

Dear Brain Trust,

I have a technical problem that I'm a few clues shy of solving. Can you help?

I have a personal web site, which I built using an SSG called Yellow. I'm using a few of their extensions, most importantly Blog. The way you use Yellow is to download and unpack a ZIP file, download any extensions you want into that directory structure, and add your content (also into that directory structure). The source is on GitHub but they also give you these ZIP files.

Last summer I downloaded those ZIP files, unpacked them, started tweaking things, and added my own content. I never cloned their repositories; I just took the ZIP files. Eventually I figured out that the easiest way for me to deploy my site was to use GitHub: I created a private repository, into which I added my then-current versions of both the tooling and the content, and I update it as needed (for example to add this post).

Yes I now know this was the wrong way to go about it. Apparently we won't have gotten "send clue back in time" working in my lifetime.

Since then, they've made some updates that I would like to take advantage of. I want to update to the new version, incorporating the changes I made to the previous version (figure out what they were and how to apply them). And I want to figure out a better way to organize this so that the next upgrade is more straightforward.

I imagine that what I wanted to have done instead was to fork their repos, apply my changes, make a separate repo for my content, and (do magic here) so it all works together. I don't know what that magic is. I'd like to check my assumptions about this being a better approach. Is there some other way I should be managing this? Another way to think about it is that my project (my site) has GitHub dependencies (those other two repositories); I'm not familiar with how dependencies are typically managed.

I mentioned I'm using GitHub for deployment. More specifically: I make edits on my personal machine, commit and push, and then on the hosting server I pull and, wham, the site is up to date. There's no explicit build step and I'm not fussing with rsync. My "aha" moment was that git can already figure out what's changed and needs to be pulled, so why should I have to? I like this simplicity.

I have found the version of the blog extension I started from (thank you for explicit version numbering), so it is possible to identify the changes I made to the original.

Should I create new repos (or forks) from the previous version, apply my changes, get that working, and then try to do the upgrade from there? How should I manage the multiple git repositories so that everything ends up in the right places? There's one repo for the base system (yellow), one for all the extensions (which overlays the file structure of the base system), and then I need a place for my actual content. How do I do this?

Comments

[aphar]

if you clone a repo, you cannot share your changes between boxes (or at least it is way harder).

fork it, and you will have a github copy of all your changes backed up just in case.

good luck!

[andrewducker]

Yes - a cloned version you'd need to set up a branch if you wanted to keep your changes separate from the main version, and they probably wouldn't let you push a branch to their repo. So keeping your version entirely separate means having a fork of it.

[cellio]

Makes sense.

Fast-forward six months and suppose I want to pull in their new changes. How would I most efficiently do that?

[andrewducker]

Assuming you're using GitHub:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[cellio]

Ah, thanks! Yes, I'm using GitHub, and getting the upstream changes onto a branch to allow normal merging is the clue I was missing.

[rhialto]

Maybe I'm misunderstanding what you mean here, but I would do my own changes on some fresh branch with a fresh name, based on the upstream main branch. This way, you can incorporate upstream changes to the main branch without any chance of conflicts because the main branch would always reflect upstream (although sometimes it would fall behind temporarily).
Then on your own branch, you can merge in the changes now and then. If you want to get fancy you could review the changes and leave out the ones you don't like (but that means that from then on, plain merges from the upstream main branch probably bring the unwanted changes in after all, so once you start cherry-picking, you probably need to keep doing it).