Merge attribution and contributor docs from main to 2.0

[ksen0]

This is a draft - not sure if this is a good idea. But the challenge it's trying to solve is that non-code parts of the repository will certainly diverge more frequently than it makes sense to do code merging, and already many features in 1.x that have a parallel patch in dev-2.0 achieve this through two separate PRs.

For example, the main branch is still the source of truth for contributor list, and the main place people can fix typos and make translation suggestions. Ideally, dev-2.0 does not lag behind.

In this commit: tone that unit testing has an extra section in dev-2.0 but not in main - does it make sense to actually have that section on both branches, and indicate it has to do with 2.0? Does that make it more or less readable / locatable, since navigating these .md files on github initially presumes main tree, not a specific branch tree.

git checkout dev-2.0
git pull
git checkout -b new-branch-name
git checkout main -- contributor_docs README.md CODE_OF_CONDUCT.md CONTRIBUTING.md .all-contributorsrc 

This idea occurred when I was experimenting with cherrypicking only those commits that do not touch src/ or test/:

for commit in $(git log dev-2.0..main --reverse --format="%H"); do
  if ! git diff-tree --no-commit-id --name-only -r $commit | grep -q "^(src/)"; then
    echo $commit
  fi
done > cherry-pick-list.txt

while read commit; do
  git cherry-pick "$commit" || { echo "\n\nConflict at $commit\n\n\n\n"; break; }
done < cherry-pick-list.txt

(Technically should also have excluded package.json and test, but the following issue would still apply.) This approach does not work, because it removes too many commits - from the total 170+, only a dozen remained. Seems quite a few commits do not isolate code/tests/contributor docs, so the result did not look reasonable. Literally cherrypicking commits touching all-contributors list and README is extremely effort-intensive because there's a merge conflict almost every time - Unless I'm missing something?

I also did try to just include patches of commits just over these sets of files:

git sparse-checkout init --cone
mkdir sparse-include
echo "contributor_docs/" >> sparse-include/list
echo "/README.md" >> sparse-include/list
echo "/CODE_OF_CONDUCT.md" >> sparse-include/list
echo "/CONTRIBUTING.md" >> sparse-include/list
echo "/.all-contributorsrc" >> sparse-include/list
git sparse-checkout set --no-cone --stdin < sparse-include/list
rm -r sparse-include

git read-tree --prefix=temp-main/ -u main

But the result was very unconvincing, it seemed more likely to lead to bigger github problems later on, because excluding the parts of commits that impacted src or test directories would have to be done manually. It seemed very fragile as an approach.

So this was my solution to the problem of cherry-picking commits involving attribution list and contributor docs specifically, which are parts of the repository that will need to be kept consistent between the branches. on a regular basis I'm not attached to this approach, but I do think it would be great to have a way to quickly keep the branches up to date documentation-wise!

[ksen0]

@davepagurek This is an experimental PR, critique welcome, I was trying to think of an efficient way to keep the non-code parts of the branches in sync. It raises the question: assuming this is only applicable in 2.0 (is that the case, actually?), does it make sense to add it to the main doc on unit testing but with a note that it applies to dev-2.0 only?

[davepagurek]

We have snapshot tests on both, but we've updated how the system works in 2.0 and used a new diffing algorithm now that we have more tests. So, adding it to main makes sense, and we can mention that the algorithm described is for 2.0, and 1.x uses something similar but simpler and less robust.