Felipe Sateler writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> On 29 July 2015 at 07:34, Ian Jackson <ijack...@chiark.greenend.org.uk> wrote:
> > 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`?
Maybe. I'm afraid I don't know for sure how gbp works so it may be
that the workflow is more complicated.
I got the impression that gbp normally works with a patches-unapplied
tree. Is that correct ? If so then an additional gbp step may be
needed, to convert the tree to patches-applied.
Each of Debian's git integration and patch management tools seems to
have invented its own: branch structure; git tree contents rules;
workflow; approach to documentation.
I'm hoping that there will come to be documentation about how to use
each one with dgit. I think that documentation depends mostly on
properties of the tool and ought probably to live in the tool package.
I'm thinking of filing wishlist bugs against gbp and git-dpm, along
these lines, at least. But I need to write up something useful that
explains to the maintainer of each git-foo tool what the technical
requirements are (and give some hints about what information the user
is likely to want).
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21944.52120.301582.363...@chiark.greenend.org.uk
