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`?
--
Saludos,
Felipe Sateler
Reply to: