This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help with new GCC git workflow...

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]