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
❦ 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
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
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
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
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:
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
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
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
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
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
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.
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
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
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
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)
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
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
>
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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 mostly fine.
What I'd really like to see is a page like
37 matches
Mail list logo