I’m curious if any experimentation has been done with the `git cherry-pick` command? This sounds like the ideal use case where it would preserve the history and give the PR initiator co-authorship. You might have already explored this, but just wanted to mention it. Here’s a small article explaining a similar use case: http://technosophos.com/2009/12/04/git-cherry-picking-move-small-code-patches-across-branches.html
> On Feb 7, 2023, at 4:32 PM, John Gemignani <john.gemign...@bitnine.net> wrote: > > Hi All, > > There is a need to discuss our strategy going forward for migrating commits > from, as an example, AGE for PG 11 (called PG11 from this point) to AGE for > PG 12, 13, etc. (called PG<version>, from this point) for newly supported > PostgreSQL version branches. > > First, I'm no Github expert and welcome any viable, potential alternatives. > So, please do add suggestions or comments. > > The issues that arise come down to the *author *and *co-author* of the work > being moved from one version to another. These issues are due to the > creation of newly supported PostgreSQL version branches and the adding of > commits that were not part of the previous version, at the time of the > creation of these new branches. > > Please note: Once a new branch is synchronized (brought up to current), it > will be up to the individuals who put forth a PR, to apply it to applicable > versions. We will only be migrating commits to synchronize newly created > branches. This means that, once a branch is synchronized, any new PRs > added, are the responsibility of the PR creators. For example, if one > creates a PR for PG11, and PG12 and PG13 have been synchronized at the > time, it will be up to that person to create a PR for PG12 and PG13. > > As far as I'm aware, other than modifying patch files directly, there are > only 2 ways to migrate a commit from one separate branch to another. > Remember, these branches are diverging. > > 1. Extract a patch manually, apply it to a local feature branch, make > sure that everything works as expected, rebase it to the local PG branch, > then push that branch back to the remote. > 2. This is similar to #1, except it is done as a PR. > > Using option #1, the original author of the patch is preserved, but there > is no co-author information for the person doing the migration. > Additionally, it doesn't use a PR, so isn't as trackable. > Using option #2, the original author is changed to the PR creator and the > original author is now the co-author. > > Our preference would be to preserve the original author, as the author, and > have the person writing the PR become the co-author. However, it doesn't > appear as if that is possible. The co-author is important to keep as a > record of who did the work migrating the PR and, they potentially did a lot > of work to migrate that patch. > > Being faced with these two options, neither of which are ideal, we're > leaning towards option #2. > > This is where anyone who has any comments, experience, or expertise is > welcome to speak up. Additionally, if there are any reasonably viable > alternatives, we would be interested in hearing them out. > > Otherwise, provided no input or reasonable alternatives we will be going > with option #2. > > Thank you to everyone in advance, > > John Gemignani
