[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Ad-hoc survey of existing Debian git integration tools

On 29 July 2015 at 07:34, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> Felipe Sateler writes ("Re: Ad-hoc survey of existing Debian git integration tools"):
> > On Tue, 21 Jul 2015 18:46:47 +0100, Ian Jackson wrote:
> > > That is, the dgit git tree contains the patches in debian/patches/ but
> > > also contains the implied changes in the main source code.  If you add
> > > commits yourself to the dgit git tip, new patches will generated from
> > > your commits.
> >
> > Does that mean that if I fix or refresh a patch then my quilt series will
> > contain the original and the fixup as patches?
> I find this question confusing.  I'm not sure of the situation you are
> imagining yourself in.
> dgit is not a patch management tool.  It is a way to share (and if
> necessary invent) a canonical git representation for each package.  So
> dgit is not a competitor to git-dpm or git-buildpackage.
> If you are the maintainer, and like to use git with `3.0 (quilt)',
> then you may use whatever git-foo tool you like to manage the patch
> stack - provided it can generate a `patches-applied packaging branch'.
> dgit does not make the interaction between `3.0 (quilt)' and git any
> easier or harder: you should just use existing tools.
> If you are an NMUer or a downstream using dgit, you should usually
> make plain git commits (with no changes to the patch stack).  dgit
> will generate a separate patch for each of your commits.  You should
> leave rebasing/squashing/refreshing to the maintainer.  This rule is
> necessary because if two developers both rebase/squash/refresh in
> parallel, it is difficult to merge their work.

OK, so for a regular maintainer using quilt and git-buildpackage, the
only change to integrate dgit into the workflow is to replace `gbp
buildpackage && dput` with `dgit git-build && dgit push`?


Felipe Sateler

Reply to: