Re: Introducing dgit - git integration with the Debian archive
Raphael Hertzog writes ("Re: Introducing dgit - git integration with the Debian archive"):
> On Fri, 23 Aug 2013, Ian Jackson wrote:
> > The thing that really bothers dgit is that it is not always possible
> > That is, if I do this:
> > 1. dpkg-source -x
> > 2. edit things
> > 3. dpkg-source -b
> > 4. dpkg-source -x on the output from stage 3
> > then the output of step 4 is not always the same as the input
> > to step 3. Typically the output of step 4 has additional metadata
> > files inside the tree.
> Well, by default step 3 fails if you have upstream changes.
I'm not sure what you mean by "upstream changes". Do you mean changes
outside the Debian directory ? If so I wasn't aware of it. Perhaps I
didn't read the manpage clearly enough. I think that is also broken.
It seems to me that the most basic requirement of an archive source
format is that the four operations I describe above should work and
(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
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.
> > For some more sophisticated workflow, it is necessary to round trip
> > the patch stack through the archive and back into git.
> I'm not following you here. Can you elaborate ? ("round-trip through the
> archive" doesn't mean anything obvious to me)
I would like to focus on fixing the existing situation before getting
into this discussion, so I'm afraid I'm not going to reply to this
part right now.
> > This is a command-line option ? How does one specify in the source
> > package that this is to be used.
> You put "single-debian-patch" in debian/source/local-options (or …/options
> if you want to keep it in the generated source package).
> (=> with "local-options" this is another case of something that you can
> have in your tree and that you won't have in the unpack of the generated
> source package)
It seems to me that it is the maintainer who determines the source
package format. Therefore putting this in local-options makes no
> > The repos are created only by dgit users. Different dgit users see
> > the same commits from the archive: the synthesised commits are
> > deterministic.
> OK, assuming that they are created on top of the same commit I guess.
There is an intervening pseudo-merge. So all dgit users will
create the same root commits with perhaps some different pseudo-merges
if they do dgit fetch at different times and so see different states
of the dgit/suite branch in dgit-repos.
> Are those commits replacing all the files or are they actually a merge of
> changes from upload_n-1 to upload_n in the git repository?
Each upload is represented as a new root commit whose tree contains
the files which are the result of "dpkg-source -x". This is then
merged into the existing head of the suite's branch in dgit-repos with
a pseudo-merge (ie, a merge which takes content only from one of the
parents). The dgit-repos suite branches are fast-forwarding.