Differences between revisions 6 and 7
Revision 6 as of 2009-04-13 09:50:34
Size: 3562
Editor: SeanFinney
Revision 7 as of 2012-07-25 17:08:04
Size: 3413
Editor: ThomasKoch
Deletions are marked like this. Additions are marked like this.
Line 77: Line 77:
## You can add other _helpful_ links here.
##See also:
## If this page belongs to an existing Category, add it below.
## CategorySomething | CategoryAnother

Migrating to Git from SVN for debian PHP packaging

We have moved to git! for helpful usage info, see PHP/GitUsage.

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

however, with the "best" option there are some problems converting to 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).
  • there's a lot of junk commits that really aren't too interesting anyway.

so, it sounds like we'll be going for the "better" option. Mark Hershberger has done an initial stab at this: http://mah.everybody.org/php.git .

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?
  • upstream may be moving to git, we might want to graft/filter-branch after they do that (so we could track the repo directly), though this would be the equivalent of rebasing our public repo...