HCoop / bpt / emacs.git / blame
| Commit | Line | Data |
|---|---|---|
| 51603dab GM |
1 | NOTES ON COMMITTING TO EMACS'S BAZAAR REPO -*- outline -*- |
| 2 | ||
| 3 | * Install changes only on one branch, let them get merged elsewhere if needed. | |
| 4 | In particular, install bug-fixes only on the release branch (if there | |
| 5 | is one) and let them get synced to the trunk; do not install them by | |
| 6 | hand on the trunk as well. E.g. if there is an active "emacs-23" branch | |
| 7 | and you have a bug-fix appropriate for the next Emacs-23.x release, | |
| 8 | install it only on the emacs-23 branch, not on the trunk as well. | |
| 9 | ||
| 10 | Installing things manually into more than one branch makes merges more | |
| 11 | difficult. | |
| 12 | ||
| 13 | http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html | |
| 14 | ||
| 15 | * Backporting a bug-fix from the trunk to a branch (e.g. "emacs-23"). | |
| 16 | Label the commit as a backport, e.g. by starting the commit message with | |
| 17 | "Backport:". This is helpful for the person merging the release branch | |
| 18 | to the trunk. | |
| 19 | ||
| 20 | http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00262.html | |
| 21 | ||
| 22 | * Installing changes from your personal branches. | |
| 23 | If your branch has only a single commit, or many different real | |
| 24 | commits, it is fine to do a merge. If your branch has only a very | |
| 25 | small number of "real" commits, but several "merge from trunks", it is | |
| 26 | preferred that you take your branch's diff, apply it to the trunk, and | |
| 27 | commit directly, not merge. This keeps the history cleaner. | |
| 28 | ||
| 29 | Or use shelves; or rebase; or do something else. See the thread for | |
| 30 | yet another fun excursion into the exciting world of version control. | |
| 31 | ||
| 32 | http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00086.html |