Re: Intent to commit craziness - source package unpacking

2016-09-29 Thread Ian Jackson
Guido Günther writes ("Re: Intent to commit craziness - source package 
unpacking"):
> The authorship and subject information is taken from the patch if
> available or made up from the filename and committer when not.
> 
> If patches in the series file are in subdirs of debian/patches we store
> that in "Gbp-Pq: topic" in the commit message. The patch name itself
> is stored in "Gbp-Pq: Name" we can reproduce it on "gbp pq export"
> independent from the patch's subject.

Right.

> >   Bear in mind that because the output of gbp-pq import doesn't
> >   contain debian/patches, I would need to rewrite its output (perhaps
> >   with git-filter-branch).
> 
> 'gbp pq import' does have 'debian/patches' since it just puts the
> patches that are in debian/patches on top of the unpatched source
> tree. In contrast to your solution it doesn't try to be able to
> roundtrip without changes for any given series on "gbp pq export". This
> is only true if the series was also created by "gbp pq" (or adheres to
> what git-format-patch does).

Currently the output of dpkg-source --commit doesn't look much like
the output of git-format-patch.

I have tried to make dgit produce patches (when it needs to produce
patches) that look like dpkg-source --commit.  But maybe it should
produce patches using git-format-patch (or that look like
git-format-patch).

Thanks for suggesting libvirt as an example.  I will play about with
it.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss


Re: Intent to commit craziness - source package unpacking

2016-09-29 Thread Ian Jackson
Ian Jackson writes ("Re: Intent to commit craziness - source package 
unpacking"):
> Guido Günther writes ("Re: Intent to commit craziness - source package 
> unpacking"):
> > Hi Ian,
> 
> Hi, thanks for your attention.

Please disregard this email.  I hadn't finished editing it!

Ian.

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss


Re: Intent to commit craziness - source package unpacking

2016-09-29 Thread Guido Günther
Hi Ian,
On Wed, Sep 28, 2016 at 11:09:03AM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Intent to commit craziness - source package 
> unpacking"):
> > Thanks for your comments.  I feel unblocked :-).
> 
> So, I now intend to go and implement my plan.
> 
> There will be a little while (perhaps a few weeks) before I am in a
> postion to release this in dgit 2.0.  But after I do that, I will not
> want to change the import algorithm again: it is important that the
> imports be as stable as possible.
> 
> So now would be a good time for maintainers of git packaging tools (eg
> git-dpm and gpb) to have an opinion about the detail of the generated
> pseudohistory - in particular, the detail of the commits generated
> from the `3.0 (quilt)' dpkg-source patches.

>From what I understand the format to produce is not compatible in what
"gbp pq" currently expects, that is just one commit per patch without
any chnages to other files in debian/ (like the series file). 'gbp pq'
is just a helper for handling the quilt patches, not more.

I don't understand yet how you expect the actual workflow between gbp
and dgit to look like but I would be happy to have a look at a prototype
dgit created history. I can e.g. imagine telling "gbp pq" to filter out
chnages in debian/ during patch creation.
 
> Also, I would welcome suggestions for what kind of compatibility test
> I could perform on such a series of commits.  dgit has an extensive
> test suite (advertised via autopkgtest) which would be well-suited to
> such a compatibility test.
> 
> An example of such a tree might be, "split out the patch queue part of
> the git pseudohistory and feed it to gbp-pq, asking gbp-pq to
> regenerate the source package, and expect the output to be identical
> to the original input source package".  Guido, if I get the
> preconditions right, should I expect such a test to pass ?  Is there a
> risk it would break in the future due to changes in gbp-pq's
> conversion algorithm ?

It would be nice to have "gbp pq" reproduce debian/patches identically
on such a tree but I would rather have a look at how the dgit created
history finally looks once you implemented it. gbp-pq's conversion
algorithm is not expected to change (at least in the default
configuration, I have some other ideas about patch handling but that
would not modify the current workflow ).
Hope that helps,
 -- Guido

> I confess that I am less familiar with git-dpm.  I don't know what I
> should be thinking about to try to make the output most useful to
> git-dpm users.
> 
> (I also don't know whether the goals of helping git-dpm users and
> gbp-pq users, and potentially users of any other tools, are in
> conflict.
> 
> It would be annoying if these tools would disagree about the best form
> of import of a particular patch queue: the import algorithm should be
> the same for different dgit users, so I wouldn't be able to make this
> a per-user configuration option and would have to choose..)
> 
> Thanks,
> Ian.
> 
> -- 
> Ian Jackson    These opinions are my own.
> 
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
> 
> ___
> vcs-pkg-discuss mailing list
> vcs-pkg-discuss@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
> 

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss