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

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.


Reply to: