I haven't done anything with cherry picking but I will look into this to see if it is helpful.
john On Wed, Feb 8, 2023 at 11:18 AM Nicholas Sorrell <n...@cint.io> wrote: > 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 > >
