(reordered slightly)
Thanks for the information.
Raphael Hertzog writes ("Re: Introducing dgit - git integration with the Debian
archive"):
> On Fri, 23 Aug 2013, Ian Jackson wrote:
> > Ie:
> > (i) dpkg-source -b should be able to run on any reasonable tree
> > (ii) dpkg-source -b should not modify the directory it is run in
> > (iii) dpkg-source -x should always produce the same tree as
> > was fed to dpkg-source -b
> > But as I understand you, `3.0 (quilt)' violates these and this
> > deliberate.
...
> Well doing the right things with "3.0 (quilt)" means (for most people)
> to keep the source package tree actually usable with quilt, so actually
> recording "non-quilt managed" changes in a new quilt patch.
IMO the design should have been that the quilt user would do this
after having unpacked the package. I still think it's fair to
describe the failure to maintain the properties (i)..(iii) above as
"braindamage".
But never mind, I will work around it.
> > If I have understood you, dgit won't work properly if you make the
> > "wrong" kind of change, so I need to either have this fixed, or (more
> > likely) to work around it (and bitch some more in the manpage). Does
> > "dpkg-source --commit" make any changes other than to quilt metadata ?
> > Perhaps dgit push should do that automatically.
>
> dpkg-source --commit adds a new patch in debian/patches/, it adds the
> corresponding quilt metadata, and it might also modify
> debian/source/include-binaries in case you have (modified/new) binary
> files that can't be represented in a quilt patch.
I will hope that the user who doesn't care about the innards of
the `3.0 (quilt)' format doesn't care about all of that.
> But you should be aware that it's an interactive command, it will ask for
> the patch name (thought this can be avoided by feeding it on the command
> line) and it will run sensible-editor to let the user edit the DEP-3
> metadata on top of the generated patch.
I will RTFM to use it in some noninteractive way by generating the
arguments automatically.
> And the content is taken from the parent which represents the uploads? So
> basically you overwrite any other changes that might have been done since
> the last upload? Otherwise there's no point in that pseudo-merge if it
> doesn't grab the changes made by this upload.
I think you're confused. We are talking here about the import from
the archive, not the upload to it.
But it is true that if you make an upload you overwrite the changes
made in any recent uploads you haven't explicitly merged into what
you're uploading. I think this is a fundamental misfeature of the
archive.
But dgit users won't overwrite each others' changes, because they are
pushed to the fast-forwarding dgit suite branch before upload.
> So basically the difference with git-buildpackage is:
...
> Are there any other important differences?
dgit is a lot simpler than git-buildpackage. I think the manpage
should answer this questions. I'm not really qualified to talk about
git-buildpackage in detail.
> The centralization is a nice bonus but the fact that it's required is
> somewhat problematic, I don't see the point in duplicating data in another
> git repository when all my packages are already using git (and often in
> collab-maint so all DD have write access). It would be nice if it could
> rely on the Vcs-Git fields available in the archive and then optionally
> work on those repositories instead of dgit.debian.net.
The central repositories are fundamental to the design.
I chose not to use collab-maint because that would have involved
getting agreement from everyone who uses collab-maint that it was OK
for dgit to create its branches and tags there. If you want to
combine dgit-repos and collab-maint, that would certainly be
technically possible. Please go away and get the required consensus
and get back to me and I will make it so :-).
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21016.51167.494885.568...@chiark.greenend.org.uk
