[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Document current policy for development with git.
From: |
Ralf Wildenhues |
Subject: |
Document current policy for development with git. |
Date: |
Tue, 27 Jul 2010 21:43:59 +0200 |
User-agent: |
Mutt/1.5.20 (2010-04-22) |
Hi Stefano, all,
I've rewritten the HACKING section on development with git a bit to
better reflect what I currently think is a good way to go on. Patch
for maint. Comments appreciated.
FYI, I am waiting for regenerating the in-tree files with Autoconf 2.67
until the official tarballs have come out.
Thanks,
Ralf
Document current policy for development with git.
* HACKING (Working with git): Overhaul.
Prompted by suggestion from Stefano Lattarini.
diff --git a/HACKING b/HACKING
index ee85917..8facbeb 100644
--- a/HACKING
+++ b/HACKING
@@ -92,28 +92,46 @@
================================================================
-= Working with git/CVS
+= Working with git
* To regenerate dependent files created by aclocal and automake,
use the `bootstrap' script. It uses the code from the source
tree, so the resulting files (aclocal.m4 and Makefile.in) should
be the same as you would get if you install this version of
- automake and use it to generate those files.
+ automake and use it to generate those files. Be sure to have the
+ latest stable version of Autoconf installed.
* Dependent files aclocal.m4, configure and Makefile.in in all
directories should be up to date in the git repository, so that
the changes in them can be easily noticed and analyzed.
-* Avoid merge commits on the master branch of the public git repository.
- For unpublished changes in your development tree, it's easiest to
- rebase against the current master before applying them, this preserves
- a linear history.
-
-* For changes to appear in more than one branch, apply them to the
- master branch and then cherry-pick them to the stable branch from
- master if possible. This keeps the master uncluttered and preserves
- meta-data on the stable branches.
-
+* The git tree currently carries a number of branches: master for the
+ current development, and release branches named branch-X.Y. The maint
+ branch serves as common ground for both master and the active release
+ branches. Changes intended for both should be applied to maint, which
+ should then be merged to release branches and master, of course after
+ suitable testing. It is advisable to merge only after a set of related
+ commits have been applied.
+
+* For bug fixes of long-standing bugs, it may be useful to commit them to
+ a new branch based off of the commit that introduced the bug, and merge
+ this bugfix branch into active branches that descend from the buggy commit.
+
+* There may be a number of longer-lived feature branches for new developments.
+ They should be based off of a common ancestor of all active branches to
+ which the feature should be merged later. The next branch may serve as
+ common ground for feature merging and testing, should they not be ready
+ for master yet.
+
+* master and release branches should not be rewound, i.e., should always
+ fast-forward, except maybe for privacy issues. The maint branch should not
+ be rewound except maybe after retiring a release branch or a new stable
+ release. For next, and for feature branches, the announcement for the
+ branch should document rewinding policy.
+
+* In order for rebasing and merging of ChangeLog entries to work seamlessly,
+ install and configure git-merge-changelog, currently available as gnulib
+ module.
================================================================
= Test suite
- Document current policy for development with git.,
Ralf Wildenhues <=