Sean Whitton writes ("Bug#833025: dgit: quiltify smash strategy shouldn't fail
when current patch queue fails to apply"):
> The smash strategy should not fail when the current contents of
> debian/patches/ does not apply cleanly to the upstream source.
Indeed.
> Intuitively, one meaning of the smash strategy is "I know that no sane
> linearisation can be automatically generated from the git history, so
> just give me a diff."
My concepton of --quilt=smash was to allow an NMUer to generate a
single additional patch out of what in git is a merge (or other
excitement).
> For example, today I merged a new upstream version to a package with a
> single patch in debian/patches/. The patch no longer cleanly applies,
> but I know that the only modifications I've made to the upstream source
> should go into that single patch. So I should be able to just use the
> smash strategy, and then rename the resulting patch that dgit leaves in
> debian/patches/.
I don't think I would object to a dgit --quilt= strategy which did
what you want. However:
I don't think I would want to change the "smash" strategy to rewrite
existing Debian patches. That would make it more dangerous than it is
now. And:
Firstly, aren't you the maintainer of this package ? In which case if
you specify single-debian-patch in debian/source/options, the problem
will go away because the tools will all know that you don't intend to
try to keep the patches as a quilt series. (If you're not the
maintainer then how do you propose to generate the NMU diff?)
Secondly, you can achieve the effect of a putative
dgit --quilt=smash-all by doing something like this:
git rm debian/patches/[name of patch]
>debian/patches/series
git commit -m 'Throw away old, out of date, patch' debian/patches/series
dgit --quilt=smash quilt-fixup
> The reason is that `dpkg-source --no-check -x fake.dsc' fails because
> the patches don't apply cleanly. Perhaps dgit should detect this
> failure, and respond by generating the upstream diff itself by looking
> at the orig.tar and comparing it with HEAD, put that in debian/patches/
> and be done with it. If this sounds sensible, I could prepare a patch.
I do think that it would probably be worthwhile if dgit's error
message, in your situation, were better.
Before you do any work on this area of dgit, you should probably be
aware that I have a big outstanding branch, which contains some
refactoring of these parts of dgit:
http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git/dgit.git/
That branch "master" won't be released particularly soon because I
want to finish the gbp/git-dpm compatibility work first. But you
might consider either waiting, or building on that branch rather than
on the last release.
Regards,
Ian.
