From e8e3bd0ff020b2edf6bd8955de97e45837ef98d4 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Fri, 12 Feb 2016 09:04:52 +0200 Subject: [PATCH] ; Improve merge documentation in CONTRIBUTE * CONTRIBUTE (branches): Tell how to avoid merging of non-backported changes. --- CONTRIBUTE | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTE b/CONTRIBUTE index d8e102dc7f..74d340af13 100644 --- a/CONTRIBUTE +++ b/CONTRIBUTE @@ -184,15 +184,19 @@ If you are fixing a bug that exists in the current release, be sure to commit it to the release branch; it will be merged to the master branch later. -However, if you know that the change will be difficult to merge to the -trunk (eg because the trunk code has changed a lot), you can apply the -change to both trunk and branch yourself. It could also happen that a -change is cherry-picked from master to the release branch, and so -doesn't need to be merged back. In these cases, indicate in the -release branch commit log that there is no need to merge the commit to -the trunk; start the commit message with "Backport:". gitmerge.el -will then exclude that commit from the merge to trunk. - +However, if you know that the change will be difficult to merge to +master (eg because the code on master has changed a lot), you can +apply the change to both master and branch yourself. It could also +happen that a change is cherry-picked from master to the release +branch, and so doesn't need to be merged back. In these cases, +indicate in the release branch commit log that there is no need to +merge the commit to master; start the commit message with "Backport:". +gitmerge.el will then exclude that commit from the merge to trunk. + +Some changes should not be merged to master at all, for whatever +reasons. These should be marked by including something like "Do not +merge to master" or anything that matches gitmerge-skip-regexp (see +gitmerge.el) in the log message. ** Other process information -- 2.39.2