This repository loses the git history of denoland/manual

[not-my-profile]

I only found out about this by seeing that my PR denoland/manual#689 has been "rolled in" ... apparently this means that my changes have been merged without any attribution to me whatsoever in a commit 0bbfd47 titled "pick up docs update from last 30 days" solely attributed to @kwhinnery.

I would like you to revert my changes to npm_specifiers.md and properly reapply them so that I am attributed to my changes as the git author.

I only looked into this a bit further and I think the issue is actually much bigger:

~/repos-contrib/deno_manual $ git shortlog -s | wc -l
343
~/repos-contrib/deno-docs $ git shortlog -s | wc -l
4

Over 340 people have contributed to the deno_manual. This repository replaces the old repository without attributing any of the previous contributors, which I'd consider a serious faux pas.

I don't see any reason why the denoland/manual repository had to be deprecated in the first place, the repository could have simply been renamed ... even if all the files are moved to runtime/manual/ git would still retain its authorship information. In case this repository combines the files of several repositories, they could (and should) be merged with --allow-unrelated-histories rather than just recreating the files without their history.

[kwhinnery]

Hey there - thanks for starting this conversation. While migrating content from the manual, it was definitely not my intent to obscure contributions to the manual to date. Merging and moving content from a denoland/manual remote with the --allow-unrelated-histories option would have been a much more elegant solution for this migration and preserved more granular git history.

Here's what I've done to attempt to restore attribution within our git history:

I added via merge commit the content from the old manual without moving it to replace the newer content (I've had to touch most files during the migration, and didn't want to go through the process again). This had the effect of restoring the full list of contributors when running git shortlog -s -n at the command line, and within the GitHub contributors UI.

I added your commits from denoland/manual#689 by reverting your changes in main, adding your fork as a remote, merging them into a local branch, making the necessary changes to the content for Docusaurus, and merging the result. Your commits are now a part of the repo, but the actual file history was not updated yet despite my replacing it with your version from the manual.

I will continue to fight git on the second front, but let me know if you'd prefer for your changes to be reverted again until such time as I can fix the file history.

[not-my-profile]

Thanks for attempting to fix this.

git shortlog -s isn't really the only command that matters, it was just an example. Ideally git log --follow and git blame would point out who contributed to a specific file .md file in runtime/manual/.

I've had to touch most files during the migration, and didn't want to go through the process again

This is not just about attribution, it's also about transparency. It's just very much unclear which changes you've actually made.

let me know if you'd prefer for your changes to be reverted again

It's alright, I don't mind that much.

[kwhinnery]

Acknowledged and agreed that the lack of per-file history in this repository is not optimal. For the most part, the changes I made moving the content to Docusaurus were copying and adjusting internal links to follow Docusaurus conventions.

If the lack of per-file version history ends up being a major pain point for future development, we can look into re-migrating the content from the manual. Or if someone else wants to contribute that effort, I would definitely be down to review a PR. But given that we have the change history in the previous repo (which we'll keep available indefinitely), and those changes plus the ones in this repo provide a full view into file changes over time if that becomes relevant, I don't know if I would prioritize fixing version history per file.

However, the lack of attribution explicitly in git history, the contributors report, and the README was a gaffe that needed to be corrected, and hopefully is to an acceptable degree at this point. I definitely want to continue to acknowledge and celebrate the contributions of the hundreds of folks that have provided docs changes and contributions over the years.