On 2017-01-03 16:58:21 [+0000], Ian Jackson wrote: > Looked at another way, it is trying to be a version control system, > layered on top of the Debian archive. But it is only about a quarter > of a VCS. There are no formal interfaces to do proper VCS operations. > If there is a formal interface, it is quilt(1) (which is itself very > poor. NB that is not quilt's fault: quilt inevitably has a hard job > because can't make enough assumptions).
there quilt push, pop and header which seems enough. > I think if we want to be storing patch queues we should be doing so in > a real version control system. Indeed, most people are doing that. > For now many people are using `3.0 (quilt)' as an interchange format, > but ideally we would switch to a useable git workflow that did a > similar thing, and then we could use git as our history interchange > format. I read this a few times in this thread that people want the patches in a VCS. I never saw this a missing feature or requirement on my side. I usually have git-dpm which creates the quilt series and I try to keep patches documented. Once upstream releases a new version I need to rebase all patches and this might involve manual handling if the patch(es) don't apply cleanly. Once that is resolved I have one patch again which I take as-is and can submit upstream. I can't think of an example where having a patch history somewhere else than within the patch itself is useful. My thinking is probably limited by my workflow :) Would you have an example where and how this could be usefull? > > Regards, > Ian. > Sebastian
