"Bernhard R. Link" <[email protected]> writes: > Another way to work around that is not using quilt if you are using a > vcs, but use the vcs to manage the differences and export that > information into debian/patches/. For git I wrote git-dpm[1] as some > way[2] to do this. I guess with bzr something similar should be > possible.
My perspective, as someone who uses Git to manage changes relative to upstream, is that this is pointless makework unless one has some expectation that there's some consumer for these patches. For OpenAFS, for instance, where I regularly cherry-pick changes from the upstream release branches, those patches correspond to upstream deltas that are available from upstream, and exposing them as separate patches in debian/patches just requires that I do extra work that no one cares about or will ever look at and makes my life harder when merging new upstreams. I think the combination of --single-debian-patch and debian/source/patch-header will let me collapse the changes into one patch while still preserving the other features of 3.0 (quilt), but I'm not completely sure what happens if someone then downloads such a package, hacks on it more, and then builds a new source package. Are their changes incorporated into my same patch with my same header? -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
