On Thu, 2017-03-09 at 21:13 +1100, Brian May wrote:
> Brian May writes:
>
> > git read-tree --reset -u upstream
> > git reset -- debian
> > git checkout debian
> > git rm debian/.git-dpm
>
> I have tried these steps on python-mkdocs in the debian/experimental
> branch, and then upgraded to the l
❦ 9 mars 2017 21:13 +1100, Brian May :
> The above also assumes that upstream==origin/upstream==latest
> upstream. Which means you need to have done a git pull recently on the
> upstream branch. Depending on the circumstances, using origin/upstream
> might be a better choice rather then upstrea
Brian May writes:
> git read-tree --reset -u upstream
> git reset -- debian
> git checkout debian
> git rm debian/.git-dpm
I have tried these steps on python-mkdocs in the debian/experimental
branch, and then upgraded to the latest upstream (using instructions on
wiki). Works perfectly[1].
The
On Feb 16, 2017, at 07:53 AM, Scott Kitterman wrote:
>Which is completely separate from the question of if we want to use it as a
>team. Whoever it was that suggested focusing on what (if anything) to
>replace git-dpm with (post-stretch) and leave the dgit discussion for later,
>I completely agre
On Thursday, February 16, 2017 12:42:59 PM Dimitri John Ledkov wrote:
> On 16 February 2017 at 11:31, Piotr Ożarowski wrote:
> > Are you guys seriously considering dgit to replace anything other than
> > dput in DPMT? I'd rather go back to svn-buildpackage than use something
> > that will not allo
On 16 February 2017 at 11:31, Piotr Ożarowski wrote:
> Are you guys seriously considering dgit to replace anything other than
> dput in DPMT? I'd rather go back to svn-buildpackage than use something
> that will not allow me (f.e. as sponsor) to review before uploading!
One can totally review bef
Are you guys seriously considering dgit to replace anything other than
dput in DPMT? I'd rather go back to svn-buildpackage than use something
that will not allow me (f.e. as sponsor) to review before uploading!
Anyway, as DPMT admin I will block any transitions before Stretch release
(yet another
On Feb 14 2017, Scott Kitterman wrote:
> How does dgit avoid maintainer forgot to push problems without being
> limited to the granularity of one commit per upload?
It does not. Until 'dgit push' is called the next time, it will revert
to one commit per upload for the "dark" period.
I am not sur
On Tuesday, February 14, 2017 06:23:43 PM Brian May wrote:
> 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 granularit
Barry Warsaw writes:
> On Feb 14, 2017, at 06:30 PM, Arto Jantunen wrote:
>>The patch-queue branch is based on the Debian branch, not upstream. Try
>>merging the new upstream version to your Debian branch, and then running
>>gbp pq rebase.
>
> This confuses me, or I'm doing something wrong. With
On Tue, 14 Feb 2017 at 11:44:33 -0500, Barry Warsaw wrote:
> So how do I drop a patch with gbp-pq?
rm debian/patches/this-got-fixed-upstream.patch, vi debian/patches/series,
commit? :-)
Or more generally, to do it the git way, if the rest of the patch series
might need non-trivial adjustment:
gi
On Feb 14, 2017, at 06:30 PM, Arto Jantunen wrote:
>The patch-queue branch is based on the Debian branch, not upstream. Try
>merging the new upstream version to your Debian branch, and then running
>gbp pq rebase.
This confuses me, or I'm doing something wrong. With git-dpm the way to drop
patch
Barry Warsaw writes:
> On Feb 14, 2017, at 05:54 PM, Brian May wrote:
>>Maybe something like the following?
>>
>>git read-tree --reset -u upstream
>>git reset -- debian
>>git checkout debian
>>git rm debian/.git-dpm
>>git commit
>
> This gets closer, but there still seems to be problems.
>
> gbp p
On Feb 14, 2017, at 05:54 PM, Brian May wrote:
>Not sure how to unapply all patches. "quilt pop -a" won't work, quilt
>doesn't realize the patches are applied.
Yep, that does seem to be the problem.
>Maybe something like the following?
>
>git read-tree --reset -u upstream
>git reset -- debian
>g
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 th
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
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
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 wi
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
Brian May writes:
> https://wiki.debian.org/Python/GitPackagingPQ
>
> So far it is just a clone, I haven't tried making any changes.
I have gone through and made numerous updates.
There might be errors, as I was going from memory for some of this
stuff.
I didn't specify anything for dgit. The
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
>>
kuLa writes:
> dgit indeed is using it's own repos:
> https://browse.dgit.debian.org/
> git.dgit.debian.org
The way I understand it is that dgit is simply a replacement for the
upload operation. To implement this with the required checks, it is
recommended (but not required) that you use its bu
Brian May writes:
> [brian:~/tree … modules/factory-boy] master 255 ± dgit --gbp --clean=git
> sbuild --verbose
> Format `3.0 (quilt)', need to check/update patch stack
> examining quilt state (multiple patches, gbp mode)
> dgit: split brain (separate dgit view) may be ne
On 2017-02-10 21:11:42, Brian May wrote:
> Scott Kitterman writes:
>
> > How is that different/better than debcheckout?
>
> I am still learning dgit, however I think that dgit uses its own git
> repositories. dgit-repos. I am not sure where these are located or how
> access is controlled.
dgit
Scott Kitterman writes:
> How is that different/better than debcheckout?
I am still learning dgit, however I think that dgit uses its own git
repositories. dgit-repos. I am not sure where these are located or how
access is controlled.
>From the man page for push "This will push your git history
Nikolaus Rath writes:
> But it seems to me that you are contemplating whether or not the team
> should be using dgit. This is also not a decision that needs to be made
> prior to any switch away from dgit-dpm, you can start using dgit at any
> point.
My vague understanding is that dgit complemen
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
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 'n
On February 9, 2017 10:52:04 AM PST, Nikolaus Rath wrote:
>On Feb 07 2017, Barry Warsaw wrote:
>> On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote:
>>
>>>I know the discussion is leaning towards replacing usage of git-dpm
>>>with gbp-pq. I have nothing against it but, since we are talking
On Feb 07 2017, Barry Warsaw wrote:
> On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote:
>
>>I know the discussion is leaning towards replacing usage of git-dpm
>>with gbp-pq. I have nothing against it but, since we are talking about
>>solutions for a git-centric workflow, has anyone considere
Barry Warsaw writes:
> On Feb 05, 2017, at 04:01 PM, Brian May wrote:
>
>>What should we call the clone page?
>>
>>PqGitPackaging???
>
> GitPackagingPq ?
https://wiki.debian.org/Python/GitPackagingPQ
So far it is just a clone, I haven't tried making any changes.
--
Brian May
On Tue, Feb 07, 2017 at 10:47:00AM +, Ghislain Vaillant wrote:
> I know the discussion is leaning towards replacing usage of git-dpm
> with gbp-pq. I have nothing against it but, since we are talking about
> solutions for a git-centric workflow, has anyone considered the dgit-
> maint-merge wor
On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote:
>I know the discussion is leaning towards replacing usage of git-dpm
>with gbp-pq. I have nothing against it but, since we are talking about
>solutions for a git-centric workflow, has anyone considered the dgit-
>maint-merge workflow [1]?
As
On Tue, 07 Feb 2017 at 10:47:00 +, Ghislain Vaillant wrote:
> I know the discussion is leaning towards replacing usage of git-dpm
> with gbp-pq. I have nothing against it but, since we are talking about
> solutions for a git-centric workflow, has anyone considered the dgit-
> maint-merge workfl
I know the discussion is leaning towards replacing usage of git-dpm
with gbp-pq. I have nothing against it but, since we are talking about
solutions for a git-centric workflow, has anyone considered the dgit-
maint-merge workflow [1]?
It is very well documented and would simplify team-packaging po
On Feb 05, 2017, at 02:07 AM, Scott Kitterman wrote:
>Experimentation with a few packages to prepare for a migration and make sure
>the documentation is good, is fine. We really ought to switch for real all
>at once like we did for svn -> git. It's not much of a team repository
>without a consis
On Feb 05, 2017, at 04:01 PM, Brian May wrote:
>What should we call the clone page?
>
>PqGitPackaging???
GitPackagingPq ?
Cheers,
-Barry
On Sunday, February 05, 2017 03:59:37 PM Brian May wrote:
> Scott Kitterman writes:
> > We should probably be thinking in terms of post-release for this change.
> > During the pre-release freeze, the release team doesn't typically allow
> > changes that extraneous to fixing the specific issue they
Barry Warsaw writes:
> What I'd really like to see is a page like
> https://wiki.debian.org/Python/GitPackaging for a non-git-dpm workflow. (The
> page itself could probably use a bit of gardening anyway.) Specifically, I'd
> like to see guidance on any tasks which are different for git-pq (or
Scott Kitterman writes:
> We should probably be thinking in terms of post-release for this change.
> During the pre-release freeze, the release team doesn't typically allow
> changes that extraneous to fixing the specific issue they are letting a
> package into Testing to fix. The .git-dpm f
On Jan 31, 2017, at 02:51 PM, Scott Kitterman wrote:
>We should probably be thinking in terms of post-release for this change.
Oh, definitely +1
-Barry
On Tuesday, January 31, 2017 02:23:29 PM Barry Warsaw wrote:
> On Jan 29, 2017, at 09:39 AM, Brian May wrote:
> >I would think "gbp pq" is the most popular.
>
> I've used it on some of my non-team packages and while it takes a little
> getting used to for the standard git-dpm workflow, it's been m
42 matches
Mail list logo