Differences between revisions 1 and 2
Revision 1 as of 2010-09-08 05:57:49
Size: 3269
Comment:
Revision 2 as of 2010-09-08 06:00:01
Size: 3279
Comment:
Deletions are marked like this. Additions are marked like this.
Line 20: Line 20:
Upstream goes to a branch called ''upstream'', each upstream version that is packages is also a branch ''upstream-<version>''. The upstream for a released Debian version has a parallel branch called ''upstream-<Debian code name'', for example ''upstream-lenny''. Upstream goes to a branch called ''upstream'', each upstream version that is packages is also a branch ''upstream-<version>''. The upstream for a released Debian version has a parallel branch called ''upstream-<Debian code name>'', for example ''upstream-lenny''.
Line 24: Line 24:
{{ {{{
Line 32: Line 32:
}} }}}
Line 40: Line 40:
{{ {{{
Line 46: Line 46:
}} }}}
Line 50: Line 50:
{{ {{{
Line 56: Line 56:
}} }}}
Line 60: Line 60:
You build using {{git-buildpackage --git-debian-branch=master-sid --git-upstream-branch=upstream-<version> -us -uc}} You build using {{{git-buildpackage --git-debian-branch=master-sid --git-upstream-branch=upstream-<version> -us -uc}}}
Line 65: Line 65:
 * Keep one commit to one consistent change, use {{{git commit --amend}} in case you make mistakes  * Keep one commit to one consistent change, use {{{git commit --amend}}} in case you make mistakes

Git usage in the Common Lisp packaging Team

Still a proposal!

Recommandations for handling the Git repository.

The Git repositories are stored on Alioth, for example for clisp we have:

  • web view

  • For people with Alioth access: git clone ssh://git.debian.org/git/pkg-common-lisp/clisp.git

  • Anonymous access either one of:
    • git clone http://git.debian.org/git/pkg-common-lisp/clisp.git

    • git clone git://git.debian.org/git/pkg-common-lisp/clisp.git

Repository setup

Upstream goes to a branch called upstream, each upstream version that is packages is also a branch upstream-<version>. The upstream for a released Debian version has a parallel branch called upstream-<Debian code name>, for example upstream-lenny.

The debian/ directory lives in the debian-<upstream version> branch. This branch is created new for every new upstream release and is rebased on the new release. So in practice you go:

git checkout -b upstream-2.49 upstream-2.48
#import 2.49 here
git add ..
git commit ...
git rebase --onto debian-2.49 upstream-2.49 debian-2.48
git checkout debian-2.49
dch --newversion 2.49-1 --distribution UNRELEASED

Patches and fixes to upstreams are in patch-<name> or typo-<name> branches of the respective upstream source. These are not rebased and should be forwarded to upstream. When patches or fixes are no longer needed in the master-sid branch they are renamed to archive-patch-<name> or archive-typo-name.

The real package itself is build on the master-sid branch, which is branched into the master-testing and master-<Debian release codename> when the package moves there.

The master-sid branch is recreated on each new upstream release like:

git branch -m master-sid master-<debian package version>
git checkout -b master-sid debian-<upstream version>
git pull . patch-<name>
git pull . patch-<name 2>
etc

If you discover a problem while working on preparing the master-sid branch you fix is in a new branch, for example if you have a build-failure on sparc due to a GCC bug you can do:

git checkout -b patch-sparc-gcc-bug-in-2.49 upstream-2.49
vi ...
git commit -a -m '...'
git checkout master-sid
git pull . patch-sparc-gcc-bug-in-2.49

Don't forget to forward this new patch to upstream.

You build using git-buildpackage --git-debian-branch=master-sid --git-upstream-branch=upstream-<version> -us -uc

Other Guidelines

  • Keep the distribution UNRELEASED until we release
  • Keep one commit to one consistent change, use git commit --amend in case you make mistakes

  • Do not change debian/changelog in the patches or typo branches, note the merge explicitly

  • After each upload, the first commit should be creating a new changelog entry with distribution set to UNRELEASED
  • If upstream uses a SVC consider importing the upstream changes into the git tree.

NMU's and patches

NMU's are strongly encouraged to apply the changes directly into the git repositories.