One way to refresh a long‐lived staging branch on keyboards (or any) repo

When we have a long-lived staging branch that has gone a bit stale, doing a single mega merge is pretty unwieldy, e.g. https://github.com/keymanapp/keyboards/pull/2728 has 3073 files changed over 1060 commits, which is just not reviewable!

So instead, we break the work down into chunks.

First, make sure that you do any maintenance on the staging branch -- for example in this case we needed to update the compiler to the latest release and do a few fixups in the staging branch.

Then, we use the following to get a list of merges into master since we diverged the staging-17.0 branch:

git log staging-17.0..master --oneline --merges --first-parent

That gives us a list like this (save it to a file > changelist.txt):

...<snip first couple hundred lines>...
cf6a21bff Merge pull request #2458 from First-Peoples-Cultural-Council/fv_nuxalk
b65012bd3 Merge pull request #2459 from First-Peoples-Cultural-Council/fv_dane_zaa_zaage
01d485569 Merge pull request #2455 from LornaSIL/bjcree2
5db275238 Merge pull request #2454 from quwatsunny/master
afcdec223 Merge pull request #2452 from LornaSIL/local_fonts
f15345647 Merge pull request #2450 from Runeboard/master
5375d85b8 Merge pull request #2441 from quwatsunny/master
05aed9217 Merge pull request #2447 from DavidLRowe/deseret-utf-8
7a7206a2f Merge pull request #2438 from LornaSIL/deseret
1e8d5cfdf Merge pull request #2436 from LornaSIL/gunjala_gondi
5f22b1f12 Merge pull request #2437 from LornaSIL/newa
3969d78c6 Merge pull request #2445 from dyacob/remove-unknown-ethi-fonts
03b8a7010 Merge pull request #2442 from LornaSIL/warang_citi
9e71c1676 Merge pull request #2440 from SvarnimN/newa_traditional_extended
d1f41fdfc Merge pull request #2435 from quwatsunny/master
679da0f59 Merge pull request #2421 from SvarnimN/newa_traditional_extended
97933a2ea Merge pull request #2418 from ramesh-k/malar_malayalam_1.7
2a2e747e0 Merge pull request #2424 from First-Peoples-Cultural-Council/fv_dene_zhatie
05729e43c Merge pull request #2405 from First-Peoples-Cultural-Council/fv_kwakwala_liqwala
8d028c7cc Merge pull request #2427 from dyacob/gff_tigrinya_ethiopia-v2.0.3
5c716242f Merge pull request #2425 from dyacob/gff_tigre-v1.0.2
8f4db77a6 Merge pull request #2426 from dyacob/gff_tigrinya_eritrea-v2.0.2

Then, starting at the bottom, take say 10 or 20 PRs, like so:

git switch -c chore/merge-master-to-staging-1 staging-17.0
# merging up to #2442 warang-citi
git merge --ff 03b8a7010 

Fixup any merge conflicts, review all .keyboard_info changes for work to do to merge them into .kps, and Bob's your uncle. Finish up with

hub pull-request -opd -b staging-17.0 

Start the next chunk:

git switch -c chore/merge-master-to-staging-2 chore/merge-master-to-staging-1
git merge --ff <your-next-hash>
# fix conflicts
hub pull-request -opd -b chore/merge-master-to-staging-1

And so on and so forth.

The nice thing about doing it this way is that we get bite sized chunks to review and work through. If there ends up being a big fat PR in the list we can do a smaller chunk and avoid too much pain.

Main downside is where we have multiple updates to one keyboard we may have to do repeated merge work, but that's probably a pain worth having.

In our current example, there were 194 merges into master since staging-17.0 diverged. So with ~20 merges per staging-update PR, that'll give us 10 PRs. That feels like a workable approach.