* Git based source packages (3.0 (git))
** Demonstration by David
** Full history is too much of a burden on FTP masters.
** Is something less than full history still useful?
** Readable without git? Archival format?
** Non-free materials? filter-branch at export?
** What is the point of 3.0 (custom)?

* Building packages from signed tags
** FTP masters will hate it?
** Weak hashes
** Maybe some strong hashes in the tag?

* Patch exporting
** quilt export is linearization
** linearization via rebasing: gitpkg hooks, git-buildpackage
** linearization via (automatic) cherry-picking
*** Examples: bibutils, trayer, systemd, nauty, racket (rebased)

* Changelogs
** exporting: git-dch
** some clever scheme based upon git-notes.

* Standardized workflows/layouts
** README.source is a bad idea
** checked out packages should either be ready to build, or debian/rules should take care of any reconfiguring
** Forced to be different from standard debian workflows.
** What is the goal
** please see the git-stuff package

* Neat prompt when in git repos with bash:
# http://lukasrieder.com/2009/07/14/extend-your-bash-ps1.html
parse_git_branch() {
  git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}
PS1='\u@\h:\w$(parse_git_branch)\$ '

* Include vcs information with zsh (svn, git, hg,…)
autoload -Uz vcs_info
precmd() {
    vcs_info
}
setopt prompt_subst
PROMPT='${vcs_info_msg_0_}%# '

Questions from IRC:
- is it preferable to carry pure-debian git-repositories (i.e. imported tarballs + debian/ on top) or may be original upstream repository + debian branch?
- opinions on having/supporting Vcs-Branch source package header field (e.g. for the cases when Vcs-Git points to upstream's repository with master as default HEAD and debian/ -- an additional branch)