Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
On February 11, 2017 4:05:46 PM EST, Nikolaus Rath <Nikolaus@rath.org> wrote:
>On Feb 10 2017, Scott Kitterman <debian@kitterman.com> wrote:
>> On February 9, 2017 8:29:32 PM PST, Nikolaus Rath <Nikolaus@rath.org>
>wrote:
>>>On Feb 10 2017, Scott Kitterman <debian@kitterman.com> wrote:
>>>>>No. You are confusing dgit with one particular way to use it. You
>can
>>>>>use dgit with the maint-merge workflow mentioned above, you can use
>>>>>dgit
>>>>>with git-dpm, and you can use dgit with gbp.
>>>>
>>>> OK. So then I gather it's effectively a layer on top of 'normal'
>>>> things like gbp-pq or git-dpm? What added value would it provide?
>>>
>>>Among other things, it enables users to run 'dgit clone', and get an
>>>up-to-date, patches-applied copy of the most recent source package.
>>
>> How is that different/better than debcheckout?
>
>It works all the time. debcheckout does not guarantee you the newest
>version (VCS may lag behind Debian archive), nor does it guarantee a
>patches applied, complete package (you might end up with just debian/,
>patches-unapplied, or even weirder things).
We know in the DPMT context what debcheckout will produce, so for our purposes they don't matter.
How does dgit avoid maintainer forgot to push problems without being limited to the granularity of one commit per upload?
Scott K
Reply to: