; Merge from origin/emacs-25

[gnu-emacs] / admin / notes / repo

diff --git a/admin/notes/repo b/admin/notes/repo
index 2d4cc2a55cf7caa688f7a4de8227e167ee9bb19c..3ab3da78071752842cf77aca1210a4686e074336 100644 (file)
--- a/admin/notes/repo
+++ b/admin/notes/repo
@@ -7,21 +7,42 @@ package archive (elpa.gnu.org).  See admin/notes/elpa for further
 explanation, and the README file in the branch for usage
 instructions.
 
 explanation, and the README file in the branch for usage
 instructions.
 

+* Install changes only on one branch, let them get merged elsewhere if needed.
+
+In particular, install bug-fixes only on the release branch (if there
+is one) and let them get synced to the master; do not install them by
+hand on the master as well.  E.g. if there is an active "emacs-24" branch
+and you have a bug-fix appropriate for the next emacs-24.x release,
+install it only on the emacs-24 branch, not on the master as well.
+
+Installing things manually into more than one branch makes merges more
+difficult.
+
+http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html
+
+The exception is, if you know that the change will be difficult to
+merge to the master (eg because the master code has changed a lot).
+In that case, it's helpful if you can apply the change to both master
+and branch yourself (when committing the branch change, indicate
+in the commit log that it should not be merged to the master, by
+including the phrase "Not to be merged to master", or any other phrase
+that matches "merge").
+

 * Installing changes from your personal branches.
 
 If your branch has only a single commit, or many different real
 commits, it is fine to do a merge.  If your branch has only a very
 * Installing changes from your personal branches.
 
 If your branch has only a single commit, or many different real
 commits, it is fine to do a merge.  If your branch has only a very

-small number of "real" commits, but several "merge from trunks", it is
-preferred that you take your branch's diff, apply it to the trunk, and
+small number of "real" commits, but several "merge from masters", it is
+preferred that you take your branch's diff, apply it to the master, and

 commit directly, not merge.  This keeps the history cleaner.
 
 In general, when working on some feature in a separate branch, it is
 commit directly, not merge.  This keeps the history cleaner.
 
 In general, when working on some feature in a separate branch, it is

-preferable not to merge from trunk until you are done with the
+preferable not to merge from master until you are done with the

 feature.  Unless you really need some change that was done on the
 feature.  Unless you really need some change that was done on the

-trunk while you were developing on the branch, you don't really need
+master while you were developing on the branch, you don't really need

 those merges; just merge once, when you are done with the feature, and
 those merges; just merge once, when you are done with the feature, and

-Bazaar will take care of the rest.  Bazaar is much better in this than
-CVS, so interim merges are unnecessary.
+Git will take care of the rest.  Git is much better in this than CVS,
+so interim merges are unnecessary.

 
 Or use shelves; or rebase; or do something else.  See the thread for
 yet another fun excursion into the exciting world of version control.
 
 Or use shelves; or rebase; or do something else.  See the thread for
 yet another fun excursion into the exciting world of version control.


@@ -45,22 +66,14 @@ variable in admin/merge-gnulib before running it.
 If you remove a gnulib module, or if a gnulib module
 removes a file, then remove the corresponding files by hand.
 
 If you remove a gnulib module, or if a gnulib module
 removes a file, then remove the corresponding files by hand.
 

-* How to merge changes from emacs-24 to trunk
+* How to merge changes from emacs-24 to master

 
 

-[The section on git merge procedure has not yet been written]
-
-Inspect the change log entries (e.g. in case too many entries have been
-included or whitespace between entries needs fixing). If someone made
-multiple change log entries on different days in the branch, you may
-wish to collapse them all to a single entry for that author in the
-trunk (because in the trunk they all appear under the same date).
-Obviously, if there are multiple changes to the same file by different
-authors, don't break the logical ordering in doing this.
+[The section on git merge procedure has not yet been written.]

 
 You may see conflicts in autoload md5sums in comments.  Strictly
 speaking, the right thing to do is merge everything else, resolve the
 
 You may see conflicts in autoload md5sums in comments.  Strictly
 speaking, the right thing to do is merge everything else, resolve the

-conflict by choosing either the trunk or branch version, then run
-`make -C lisp autoloads' to update the md5sums to the correct trunk
+conflict by choosing either the master or branch version, then run
+'make -C lisp autoloads' to update the md5sums to the correct master

 value before committing.
 
 * Re-adding a file that has been removed from the repository
 value before committing.
 
 * Re-adding a file that has been removed from the repository


@@ -83,12 +96,12 @@ which is often more appropriate.
 
 * Undoing a commit (uncommitting)
 
 
 * Undoing a commit (uncommitting)
 

-If you have not pushed the commit, you may be able to use `git reset
+If you have not pushed the commit, you may be able to use 'git reset

 --hard' with a hash argument to revert the your local repo copy to the
 pre-commit state.
 
 If you have pushed  commit, resetting will be ineffective because it
 --hard' with a hash argument to revert the your local repo copy to the
 pre-commit state.
 
 If you have pushed  commit, resetting will be ineffective because it

-will only vanish the commit in your local copy.  Instead, use `git
+will only vanish the commit in your local copy.  Instead, use 'git

 revert', giving it the commit ID as argument. This will create a
 new commit that backs out the change. Then push that.
 
 revert', giving it the commit ID as argument. This will create a
 new commit that backs out the change. Then push that.
 


@@ -102,4 +115,22 @@ again.
 * Bisecting
 
 This is a semi-automated way to find the revision that introduced a bug.
 * Bisecting
 
 This is a semi-automated way to find the revision that introduced a bug.

-Browse `git help bisect' for technical instructions.
+Browse 'git help bisect' for technical instructions.
+
+* Maintaining ChangeLog history
+
+Older ChangeLog entries are kept in history files named ChangeLog.1,
+ChangeLog.2, etc., and can be edited just as any other source files
+can.  Newer ChangeLog entries are stored in the repository as commit
+messages, which cannot be edited directly.
+
+'make ChangeLog' copies newer ChangeLog entries into a file
+'ChangeLog' that is intended to be put into the distribution tarball.
+This ChangeLog file is not put into the repository.
+
+'make change-history' copies all newer ChangeLog entries into the
+start of the newest ChangeLog history file.  These ChangeLog entries
+are thereafter considered to be old, so later uses of 'make ChangeLog'
+and/or 'make change-history' will no longer copy the entries.  To
+alter ChangeLog history, run 'make change-history', then edit
+the ChangeLog history files manually and commit your changes.