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

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

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.


Reply to: