Add blog content to separate blogs branch (#2774)

[ashishksdev]

This PR adds the site/content/blog content to the blogs branch as requested in #2774.

Does this PR introduce any user-facing change?

No — this moves documentation content to the designated branch.

How was this patch tested?

The blog folder site/content/blog was copied from the upstream main branch and committed to this blogs branch. Folder structure was verified.

CHANGELOG.md

Not applicable

[dimas-b]

I'd prefer to do CI changes related to building the site from multiple branches (main / versioned-docs / blogs) first, then move existing blogs to the new branch.

[dimas-b]

I'd prefer to delete (irrelevant) doc files in a separate PR for the sake of clarity.

[dimas-b]

Why is this changing when we just "move" blogs?

[dimas-b]

In fact, it should not be necessary to change existing blog files, I think. If the blogs branch is created from main, it should already have all the blog files.

[flyrain]

Github messed up when it generates diffs. It's a new file, instead of changes.

[ashishksdev]

Thanks for the feedback @dimas-b

I understand the CI changes should come first.
Regarding the file changes - I branched off from upstream/blogs (which was created from versioned-docs, not main). I removed the existing files and added the blog content from main, as requested by @flyrain in issue #2774.

I notice the PR is showing some files as "modified" (with red/green changes) when they should just show as "deleted". These are files from the old versioned-docs content - I'm not sure why Git is showing them as modifications instead of clean deletions. The actual blog content I'm adding is just the site/content/blog folder.

A few questions on next steps:

1. Should I wait for the CI changes to be completed before proceeding, or would you like me to fix the Git tracking issue now?
2. Regarding the doc file deletion mentioned - if this PR continues, should I remove that change and handle it in a separate PR?
   Thank you!

[dimas-b]

@ashishksdev : I commented on the issue: #2774 (comment)

[flyrain]

Thanks a lot for working on it, @ashishksdev ! As I mentioned here #2774 (comment), this PR is good as the first PR to add blog content to the new branch.

[flyrain]

Do we need directory structure site/content/blog/*? We might remove that, and use the year directory(2025) directly.

[dimas-b]

This PR alters git author associations for existing blogs. I believe this should be avoided.

[flyrain]

Another weird diffs. Should be just a new file.

[ashishksdev]

Thanks for the feedback and discussion on this PR!

After reviewing the concerns raised, I realize this PR has several issues:

1. Author information being unintentionally changed (as @dimas-b pointed out)
2. Files showing as modifications instead of clean additions/deletions
3. Cleanup of irrelevant files already in blogs (as it is based on versioned-docs) and addition of site/content/blog is in single PR, making it difficult to review

I'm going to close this PR and propose a cleaner approach:
My proposed plan:

• PR 1st: Remove all existing content from the blogs branch (as @dimas-b preferred)
• PR 2st: Add the blog content (2025 folder and _index.adoc) directly to the blogs branch, preserving original author information
  This keeps changes separated and cleaner for review.

Questions before I proceed:

1. Does this two-PR approach work for you, or would you prefer a different workflow?
2. What's the correct Git method to preserve author information when moving the blog content? Should I use git cherry-pick or another approach?
3. Should I wait for the CI discussion to conclude first, or can I proceed with clearing/adding the blog content now?

Please let me know if you have any suggestions or a different approach in mind. Happy to follow whatever works best!
@flyrain @dimas-b