Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

[Brian May]

Scott Kitterman  writes:

> 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?

When you upload a package, you upload the *.debs and push to git a the
same time. With the one dgit command that checks everything is
consistant, and tags things appropriately. I not sure of the exact
details of how the push is done yet.

I think dgit would really help with the problem I occasionally get: Does
this git source really correspond with the package that was
uploaded. Mistakes can happen in git that can result in you looking at
one git version that is very different to what was uploaded. Yes, this
does happen.

Mostly however, I think the prime benefit of using dgit would be that it
helps other non-team members maintain the package - as does happen from
time to time in the form on NMUs. We can help these people by sticking
to a standard that others can use.

It would not directly help DPMT workflow, as that mostly remains as
is. Hence my first priority would be to change to GBP PQ for work flow,
and then worry about dgit after I have had a chance to play with dgit a
bit more.
-- 
Brian May 

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

[Brian May]

Brian May  writes:

> git read-tree --reset -u upstream
> git reset -- debian
> git checkout debian
> git rm debian/.git-dpm
git commit

Of course...
-- 
Brian May 

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

[Brian May]

Barry Warsaw  writes:

> One section I think we should add at some point is instructions on how to
> manually convert to gbp-pq, at least until we do a mass conversion.

Yes agreed.

Not sure how to unapply all patches. "quilt pop -a" won't work, quilt
doesn't realize the patches are applied.

"git checkout upstream -- ." would work, but won't delete any files that
were created by the patch.

Maybe something like the following?

git read-tree --reset -u upstream
git reset -- debian
git checkout debian
git rm debian/.git-dpm

The first line sets the tree as per the latest upstream (assuming this
is uptodate) and then restores the debian directory that got
deleted. Then we just have to delete the debian/.git-dpm file and are
finished.
-- 
Brian May 

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

[Scott Kitterman]

On February 11, 2017 4:05:46 PM EST, Nikolaus Rath  wrote:
>On Feb 10 2017, Scott Kitterman  wrote:
>> On February 9, 2017 8:29:32 PM PST, Nikolaus Rath 
>wrote:
>>>On Feb 10 2017, Scott Kitterman  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

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

[Barry Warsaw]

On Feb 13, 2017, at 04:56 PM, Brian May wrote:

>There might be errors, as I was going from memory for some of this
>stuff.

Thanks Brian.  I did a quick review (without testing) and it looks pretty
good.

One section I think we should add at some point is instructions on how to
manually convert to gbp-pq, at least until we do a mass conversion.

I don't personally expect to do much package maintenance until after Stretch,
but when I do, I'll pick a package to test this workflow on.

Cheers,
-Barry