Re: Notes from the DebConf Source Format BoF
On Sun, 15 Aug 2010 at 22:28:52 +0100, Roger Leigh wrote:
> > Best practices for Git repository layout?
> > - git-buildpackage documentation is closest to that
>
> I would have to disagree here, the git-buildpackage default layout is
> far too "Debian-centric". By naming the Debian and Upstream branches
> "master" and "upstream" it's only really useful if you're importing
> upstream release tarballs.
In pkg-telepathy, I objected to 'master' for the same reasons. We use:
debian
Main Debian branch (and set foo.git/HEAD on git.debian.org to point to it,
using:
git symbolic-ref HEAD refs/heads/debian)
debian-squeeze, debian-experimental (etc.)
Other Debian branches, whenever we need to fork the packaging
upstream
git-import-orig imports of upstream release tarballs
upstream-experimental (etc.)
(occasionally) g-i-o imports of upstream release tarballs for which we're
currently targeting experimental (etc.)
debian-patches
Patches cherry-picked from upstream, rebased onto 'upstream' with each
upstream release (also occasionally debian-squeeze-patches, etc.)
We've occasionally also had Maemo release names (diablo, fremantle) as
downstream branches from the 'debian' branch, to make backports to Maemo's
older toolchain.
At the moment we use upstream orig tarballs on our upstream branch rather than
the contents of upstream git, but only because this seems to be best-practice.
I'm not entirely happy about the branch name 'upstream' for this reason (I
wanted to call it 'tarballs'), but other team members persuaded me that
following the de facto standard layout was more important.
We check in a debian/gbp.conf to make sure everyone is using this branch
structure and using pristine-tar, and alter it as necessary when branching.
For instance, see the patch to that file in:
http://git.debian.org/?p=pkg-telepathy/telepathy-glib.git;a=commitdiff;h=5176e10ea4a4c3e15aa26f1f456bafa202c2c275
When dealing with projects that need individual patches backported, I sometimes
add the upstream git repository as a remote, and cherry-pick patches that way.
In practice the debian-patches branch is troublesome; we've had to switch off
the normal shared repository "deny non-fast-forwards" option for its benefit.
If I was setting up git repositories for a new team, I'd advocate the way
gbp-pq works instead (its patch-queue branch is intended to be a
local-developer thing that's never pushed, and everyone synchronizes via the
patch series in debian/patches).
Simon
Reply to: