On Tue, 14 Jan 2020, Jonathan Wakely wrote: > > ...and this is just for changes going to trunk. How does all this change > > when I want to push changes to a release or vendor branch? > > It's pretty similar. Create a branch from the release branch, merge it > back to the release branch. > > Personally, I don't usually use branches for backports, because I only > have one in flight at a time. So I'll just make the change directly in > the release branch and push it directly from there. I rarely have
And the git approach for backports is "git cherry-pick" (though you can always use the approach of just applying a patch to a different branch if you want). I did some recently with "git cherry-pick -x -n -e" to try out the process of cherry-picking with git in GCC. -x is useful to mark the commit as a cherry-pick and -n is useful to allow editing before committing (for ChangeLogs, in particular); not sure if -e actually does anything given -n. You'll want to have set up git-merge-changelog in any clone you're doing such cherry-picking in, to avoid getting conflicts from the cherry-picking of ChangeLogs (but even without conflicts you may want to edit the ChangeLog entry before commit, to mark it as a backport). If you're cherry-picking a commit from the SVN era, you also need to edit the From-SVN: line out of the commit message (the hooks will reject the push if you don't, because it would confuse things to have such a line in a commit that isn't actually one from the repository conversion process). -- Joseph S. Myers jos...@codesourcery.com
