Git fork vs clone of template theme

[cameronelliott]

I'd thought I put a post here in can anyone else wants to discuss it.

I have a Doks repo that I cloned from the Doks template a month or so ago.

I now want to update my repo to include new features in the template theme (copy button on code blocks).

I know I can fuddle through using git cherry-pick to make that happen, and it will probably be okay.
I may be able to also use git fetch and git merge to sync to the master.
But the truth is, I don't use either of these methods often enough to really feel good about what they do to my master repo for my documentation.

But it occurred to me, had I forked the Doks template, rather than cloning it, I could simply 'sync my fork' from the upstream using the Github sync feature

That would be such an easy way to stay up to date. (Presuming conflicts don't occur)

Anyway, just curious if anyone is doing this, or if anybody has any thoughts on this approach.

Cameron

[cameronelliott]

Okay, so, I actually went ahead and switched my work from a cloned-template to a forked-template.

Just for clarity, I did this, so I could just use the Github feature 'Fetch Upstream' to easily apply Henk's
upgrades and new features without having to use git's command-line merge or cherry-picky commands to
apply new features from @h-enk

Here was the basic process I used to get there:

1. Make a fork of h-enk/doks into my repo
2. Clone it down to my system with the CLI
3. Add the repo where I had customized an older version of the Doks repo. I used git remote add other <url>
4. Fetch the entire repo where I did my work using git fetch other
5. Merge my prior with with the forked copy of Doks. git merge other/master

In my case, the merge resulted in conflicts in 6 files, probably about 10-12 conflicts:
(Places where Henk had modified the same parts of code)

Auto-merging theme.toml
CONFLICT (content): Merge conflict in theme.toml
Auto-merging package.json
Auto-merging layouts/partials/head/stylesheet.html
Auto-merging layouts/partials/head/resource-hints.html
CONFLICT (content): Merge conflict in layouts/partials/head/resource-hints.html
Auto-merging layouts/partials/head/favicons.html
CONFLICT (content): Merge conflict in layouts/partials/head/favicons.html
Auto-merging layouts/index.html
CONFLICT (content): Merge conflict in layouts/index.html
Auto-merging content/docs/prologue/commands.md
Auto-merging config/_default/params.toml
CONFLICT (content): Merge conflict in config/_default/params.toml
Auto-merging assets/scss/components/_code.scss
Auto-merging assets/scss/common/_variables.scss
Auto-merging assets/scss/app.scss
Auto-merging .github/workflows/gh-pages.yml
CONFLICT (content): Merge conflict in .github/workflows/gh-pages.yml
Automatic merge failed; fix conflicts and then commit the result.

I resolved those conflicts by hand with VSCode.
I committed all the merged files and the resolved conflicts.
In my case, I edited out the btn-copy shortcodes from my documents.
(btn-copy seems to be removed, as the fenced code blocks now directly support a Copy button.)

I tested it, and everything looks groovy.

This proceedure may or may not be for you, I am a mid-level git user, not a pro, but not a git beginner either.

I am thrilled though, now I should be able to use the 'Fetch Upstream' button to get new features if I choose.

I am kind of wondering if there are some downsides to my documentation repo being a fork rather than a
disassociated clone, but I'll give it a shot for a while and see how it goes.

[h-enk]

Interesting approach! I'm not a git pro either — input is very welcome!

[cbrands]

Actually this is probably the best way to go. If you look at the github documentation on forks. This is one of the two major usecases of forks.

Most commonly, forks are used to either propose changes to someone else's project or to use someone else's project as a starting point for your own idea.
(Emphasis mine)

[cbrands]

BTW. I just found this project today. Truly magnificent.