Re: Survey: git packaging practices / repository format

[Sam Hartman <hartmans@debian.org>]

>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

    Ian> Enrico Weigelt, metux IT consult writes ("Re: Survey: git
    Ian> packaging practices / repository format"):
    >> I'd call it the 'git-only-workflow' ;-)
    Ian> ...
    >> It's not in official Debian. I've announced it long go, but
    >> nobody here really cared. I couldn't even convice debian
    >> maintainers for little less insane scm workflows (just look at
    >> the kernel :p), but failed, so I don't waste my time anymore,
    >> instead just clean up the mess for those packages that I actually
    >> need.

    Ian> Oh.  I think I have misunderstood.  I think you are describing
    Ian> a git workflow you use as a *downstream* of Debian, not as a
    Ian> maintainer *within* Debian.

    Ian> And I think what you are saying is that you don't use source
    Ian> packages (.dsc) except maybe in the innards somewhere of your
    Ian> machinery.  I think that is a good way for a downstream to
    Ian> work.  Certainly when I modify anything locally I don't bothere
    Ian> with that .dsc stuff.

I'm certainly going to look at dck-buildpackage now, because what he
describes is a workflow I'd like to be using within Debian.

For some projects I want to ignore orig tarballs as much as I can.  I'm
happy with native packages, or 3.0 quilt with single-debian-patch.
I don't want merge artifacts from Debian packaging on my branches.
I'm happy to need to give the system an upstream tag.
I'm happy for a dsc to fall out the bottom, and so long as it
corresponds to my git tree I don't care how that happens.
I have a slight preference for 3.0 format over 1.0 format packages.  3.0
makes it possible to deal with binaries, better compression and a couple
of things like that.  The quilt bits are (in this workflow) an annoyance
to be conquered, not a value.

The thing his approach really seems to have going for it is that he
gives up on the debian history fast forwarding and instead rebases a lot
for a cleaner history.
If we could figure out a way to collaborate on something like that well,
it might be a very interesting tool to have.

--Sam