[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Feedback on 3.0 source format problems

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

> Regards,
> Ian.


Reply to: