Re: Let's talk about git management
-----BEGIN PGP SIGNED MESSAGE-----
On 19.12.2011 17:24, Stefan Fritsch wrote:
> As pointed out elsewhere, there is a public git export. But I am not
> sure we want to import that into the debian repo (the .git dir is
> about 80MB). But it would be very nice if one could (locally) add it
> as git remote and use git diff/cherry-pick/etc. seamlessly.
I think that's a good trade-off. The drawback would be that everyone
would need to setup a local remote branch tracking upstream manually but
I think that can be solved by some documentation similar to what already
That said I'd still prefer a layout where the full upstream source is
checked in as well. That comes really handy if you ever need to work on
an older package or on a package different branches (think of
backports). I made a security patch for another package just yesterday
and it turned out to be really easy to prepare it out of a complete and
consistent snapshot in the repository which was released with stable
Note, you can have the full source in conjunction with a remote upstream
branch, but you don't need to.
> I have (superficially) read a bit about git-buildpackage. It seems its
> patch-queue branches do what I want: Switch to the patch-queue branch,
> cherry-pick a commit from upstream, and then export the commit into
> the debian/patches dir of the main branch. The main branch would then
> simply be the debian source package with un-applied debian/patches
> dir. Do you think that would work?
Actually it is gbp-pq not git-buildpackage, but yes. That works. I guess
you already know, if not your proposed workflow is documented in . By
the way: This workflow does not break other people's workflow who prefer
to manage patches manually with quilt.
> Or would you prefer a different workflow/layout?
To summarize, what I'd prefer is:
* A git repository
* Having the full source in trunk
* Managing orig.tar.gz tarballs with pristine-tar (thus having a
pristine-tar branch which may, or may not be connected to the upstream
* Having a remote patch-queue (if we agree to rebase it regularly,
otherwise we better keep it local)
* Having a local (or remote) upstream branch to cherry pick commits from.
with kind regards,
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----