Hello, On Sun, Jul 31, 2016 at 11:50:40AM +0100, Ian Jackson wrote: > 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).
That makes sense. > > 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: Agreed, it should be a separate strategy. > 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 I am the maintainer, but I think that there are use cases for a dgit quilt strategy that is essentially a one-shot single-debian-patch. Suppose that the package was team-maintained, such that introducing single-debian-patch would be disruptive -- perhaps because other team members expect to introduce new, separate patches in the future. However, for now there is only one patch, so a one-shot single-debian-patch is the easiest way to fix the quilt series after merging a new upstream version. However, since just deleting the patch and running a smash quilt-fixup would be sufficient, I'm not sure whether it's actually worth adding this strategy. > > 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. Okay -- I guess this bug tracks this issue, rather than the wishlist suggestion above for a smash-all strategy. > 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. Ah, thanks for sharing this branch -- I knew you had some work going on but I didn't think it was published publicly. -- Sean Whitton
signature.asc
Description: PGP signature
