Robie forgot this bit (I think):



On 16 November 2016 at 05:38, Robie Basak <> wrote:

> FTR, I answered most questions about "why not dgit?" in the thread I
> just moved to vcs-pkg-discuss only[1].
> For some specific questions here:
> On Thu, Nov 10, 2016 at 12:31:31AM +0000, Ian Jackson wrote:
> > dgit can work on Ubuntu too, in a readonly mode.  (It would be nice to
> > make `dgit push' work on Ubuntu but that requires a suitable git
> > server, and some configration on the dgit client side.)
> A key difference with our system is that no infrastructure is required.
> It's distributed (-able), with no special git remote.
> > The --skip-patches is a vital difference.
> > Has the decision to use --skip-patches been definitively taken ?
> For now, to fulfill our use case, yes. In the general case, no, not at
> all. Probably the best place to enter into this would be in a reply to
> my fuller explanation of the reasons in [1].
> > I would like to beg you to reconsider this, in the strongest possible
> > terms.  --skip-patches generates a patches-unapplied tree.
> >
> > A patches-unapplied tree:
> Sorry, I missed reference to this list when I wrote [1]. I'll study
> these and consider how they related to my reasons later.
> > If you are making patches-unapplied trees I think you cannot possibly
> > be representing the quilt patch stack of a `3.0 (quilt)' source
> > package as a series of git commits.
> Correct. This has not been our goal.
> > Representing a `3.0 (quilt)' package that way is desirable, as it
> > means that `git blame' and `git log' can be used to see which patches
> > do what.
> In contrast, in our Ubuntu development workflow, what you mention is not
> a requirement, but what is a requirement is to use "git blame" and "git
> log" to see when the quilt patches applied were altered. We don't want
> to drill down as far as you are suggesting; instead, we want the
> information at one level removed.
> Robie
vcs-pkg-discuss mailing list

Reply via email to