How should I keep my cloned repository updated to astrowind?

[enricogallesio]

Hello!
First things first, thanks everybody for this amazing project!

My question: let's say I clone the repository today and I make changes and customize the code to my needs to build a website for a client. This takes me weeks, and then finally my client is happy and I deliver the project final build. All is good.

However, in the meantime, the astrowind project has improved. Several new versions have been released with lots of improvements, and it maybe also supports a newer astro version. My cloned astrowind repo is now obsolete, if I install a new astro version it won't even compile and I'm missing lots of new features I'd like to have. Suddenly I am stuck with an obsolete (possibly bugged) astrowind version. Or am I?

Is there a way to keep my cloned repo updated with the astrowind project while also customizing the repo to my needs, so that I won't lose the improvements in the newer versions? I guess this involves manually merging lots of code, but what is the less painful way to accomplish? Is it worth it?

I am asking because I'm already finding myself in that exact situation, and I am not sure if I should just re-customize the latest astrowind version from scratch.

thanks!

[prototypa]

Hi @enricogallesio

That question is the big question.

I have thought from extracting the widgets for a separate dependency, or creating an integration with only the internal and important things. Also separate into folders, folders clearly for core code that should not be touched and others for content. I've also thought of a command cli to create custom AstroWind or empty what you don't need. But in the end I didn't know what to do. There is also a way that could be using ``git worktree```. Finally we have never decided on any but it is a great question.

Do you have any idea of how to achieve this?

[enricogallesio]

Hi!
No, I'm afraid I don't.
I guess that if you follow closely the Astrowind repo development you can merge and apply changes step by step, but the problem is I can't really do that. So, it's likely that it gets too time consuming to do and you get stuck with the version you initially fork.

Yours seem good ideas, unfortunately I guess it's very hard to separate "core code" and content, because at least in my case I tend to make changes all over the place so, you can't really tell what is core and what is modified "content". However, I'm not very experienced with git and shared development so I may be missing some way to accomplish this...

[Hime-Hina]

I believe that Astro's theming system is too tightly integrated with the user's code. Perhaps, this issue should be resolved within the Astro framework itself. In the past, I used Hexo, and its theme code was kept separate from the main codebase, which made it more convenient for updates and migrations.

[enricogallesio]

Yes I understand, however I like the level of customization this approach lets you do and I guess you can't have both things...

[eerison]

We faced this same issue on another astro theme, then I wrote 2 articles how you could update your repository from fork

Simple one: https://blog.erison.work/posts/get-frontend-theme-updates-using-git-part-1/

Advanced one: https://blog.erison.work/posts/get-frontend-theme-updates-using-git-part-2/

I hope it helps you, let me know in the comments if it worked ;)