![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
help wanted (involves git)
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?
no subject
IIUC, you have two questions:
how to get out of the mess
you are right, you need to clone the original git repo, apply your changes (and maybe PR them upstream) - or did I miss something?
how to keep files from different git repos in one dir
IIUC, you have 3 git repos (yellow, extensions, and your content) that have to live in the same directory.
I think the solution is to use symlinks. i.e., your "actual" directory will not have any actual files, just symlinks to other directories that contain cloned git repos.
Note that, IIRC, web servers might have problems following symlinks pointing outside of their dedicated trees (for security reasons), so you might have to accommodate that.
no subject
Thanks.
Do I need to clone the original repo or fork it? The changes I've made are personal customizations, not changes I think the owners would be interested in.
Ooh, symlinks to bring in my content might work, and that'd keep the tooling separate from the content. I'll have to experiment to see if the server can handle that. 95% of my updates are to content.
no subject
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!
no subject
no subject
Makes sense.
Fast-forward six months and suppose I want to pull in their new changes. How would I most efficiently do that?
no subject
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork
no subject
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.
no subject
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).
no subject
Do you actually need the history and branches of the old repo? If not, it may be worth it to say, screw it, and make a new repo with the same files in it. (I.e., start fresh.)
Part two:
If you truly need separate repos that depend on each other, and you can't make that dependency using a package manager (i.e. import the upstream repos as packages in the downstream repo), the git-ish solution is submodules. Submodules have never worked right for me and have caused big heartache on a project in the past, but that was 8 years ago, so who knows.
no subject
I don't need the history beyond its short-term ability to, perhaps, help me reconstruct change groups (e.g. I changed these five files to accomplish X) in porting my changes again.
I don't know if I need separate repos (and I've heard alarming things about submodules too). Maybe it's enough to commit the changes from each extension separately? That is, start with the base package (yellow), add one extension (which modifies some pre-existing files), commit that, add the next extension, commit that, etc? Ignore the repo for the extensions and just unpack those ZIP files -- I can always use the public extensions repo to inspect diffs if I need to?
no subject
You don't really need submodules in most cases. Make a separate repo for your content and either make a symlink to it or simply put it in a subdirectory, which you put in the .gitignore file one level up.
You can do the same thing with any extensions that have their own repo.
If you have a separate web server (i.e. you're not using GitHub Pages), make origin point to the bare repo on the web host, with a post-update hook to update the site. I should write this up properly, shouldn't I?