Differences between revisions 2 and 3
Revision 2 as of 2009-04-07 17:03:46
Size: 3098
Editor: SeanFinney
Revision 3 as of 2009-04-07 17:04:43
Size: 3121
Editor: SeanFinney
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
 * enough: importing the latest branch tip of each release and tag it.  * enough: importing the latest branch tip of each release and tag it (stable, testing, etc).

Migrating to Git from SVN for debian PHP packaging

The pkg-php team has decided to move at least a subset of the current svn projects into git. namely, php5. other packagers are invited to follow suit but at this point there doesn't seem to be interest in forcing everything to migrate.

importing previous history

  • enough: importing the latest branch tip of each release and tag it (stable, testing, etc).
  • better: importing everything we can find (php museum, snapshots, etc)
  • best: importing svn repo

it seems we might be settling on "better" for this. i have a svn<->git repo locally but there are some problems getting this into git:

  • up until version foo, ./debian contents were directly in top-level svn
  • after version foo, contents were in ./debian, but it was a mergeWithUpstream style repository so we'd need to rebase this on top of imported upstream versions.
  • some tags saw accidental changes/deletes/comments, so extra care would be needed converting the svn "tag" branches to real git tags (i.e. grafts and filter-tree).

handling branches in git

  • debian dist branch format: debian-<codename> (+ debian-experimental)

  • upstream dist branch format: upstream-<codename> (+ upstream-experimental)

  • codenames can also include -p-u, -security, -backports, etc...
  • do we want to have other user/feature branches?

handling tags in git

  • debian tag format: debian/<version>

  • upstream tag format: upstream/<version>

  • do we want to have other user/feature tags?
  • should we force tags to be signed?

commit messages in git

standard commit messages should be a short one-line description, optionally followed by a blank line and free-form prose describing the commit.

commits that address specific bugs should mention so in the free-form section, matching the "git dch" friendly meta syntax "^Closes: #nnnnnn". this also allows for hooks to catch the specific changes and do stuff like email the bts.

handling debian/changelog

changes to debian/changelog should be distinct from the fixes that they describe. i.e. a security fix shouldn't include both the fix and the changelog entry in the same commit, it makes merging harder.

mentioning closed bugs manually is fine, but if one puts the bug ref in the commit message then this can be automatically generated too.

desired hooks

i've been interested in getting my hands a bit more dirty with git hooks, so anything that we can't assemble from existing parts i'd be happy to hack together (sean)

  • commit<->bts + tagpending integration

  • commit formatting facism?
  • not allowing changelog+changes commits
  • not allowing unapproved branches/tags
  • forcing signed tags?
  • not allowing commits under the migrated directories.

for future investigation

  • are we interested in moving from quilt to something like topgit?