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.
Ian.
Reply to: