Benny Siegert <bsiegert%gmail.com@localhost> writes: > Since pkgsrc-releng is the bit I am most familiar with, here is a > workflow that could replace the slightly crufty pkgsrc-pullup tool. I > am using git commands as an example but that could also be any other > DVCS. > > The simplest workflow, pulling up a single commit, would just need a > commitid (and a description) as input. The script can then do > > git cherry-pick $commitid I would use -x, to log the original commitid in the message. > git commit —amend # change log message so it mentions ticket #, etc > # verify the package build works > git push > > The more sophisticated case, where you pull up several commits and/or > fix merge conflicts could be: > > git checkout pkgsrc-2016Q1 > git checkout -b my-pullup > git cherry-pick a b c d > # fix conflicts, then test build > > Crucially, the steps up to here can be carried out by the *originator* > of the pull request. The releng just has to have access to the branch > somehow, e.g. by pushing it into the master pkgsrc repo, or *gasp* to > a clone on github. This makes sense to me, and for anything more than a single commit I lean to using an explicit merge commit which hosts the ticket refs. > For applying this, I see two ways: > (1) merge, force a merge commit to be created so you can annotate it with pullup ticket metadata. > (2) squash all individual commits into a single one, annotate the log message, then apply to the stable branch (either by fast-forward merge or by cherry-pick). But this seems fine too.
Attachment:
signature.asc
Description: PGP signature