Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
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 >git checkout debian >git rm debian/.git-dpm >git commit This gets closer, but there still seems to be problems. gbp pq import gbp pq export --drop That seems to round trip okay, and it just removes a few crufty lines from the patches. The problem comes when you try to rebase your patches on top of upstream. gbp pq import git rebase -i upstream (way way more commits to pick from than expected) Hmm. -Barry
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
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 pq import > gbp pq export --drop > > That seems to round trip okay, and it just removes a few crufty lines from the > patches. The problem comes when you try to rebase your patches on top of > upstream. > > gbp pq import > git rebase -i upstream > (way way more commits to pick from than expected) 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. -- Arto Jantunen
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
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 patches was to rebase interactively against upstream. That doesn't seem to work with gbp pq rebase, or with gbp pq import & git rebase -i master (or upstream). So how do I drop a patch with gbp-pq? Cheers, -Barry
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
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: git checkout debian/master # old version, patches-unapplied gbp pq import # moves to patch-queue/debian/master git checkout debian/master # or gbp pq switch gbp import-orig ../whatever.tar.gz dch git commit -m "New upstream version" git checkout patch-queue/debian/master # or gbp pq switch git rebase -i debian/master gbp pq export # back to debian/master git add debian/patches git commit -m "Refresh patches or whatever" (Substitute master for debian/master if DPMT doesn't use DEP-14, but moving to gbp pq might be a good flag day to do that too. Then you'll never have to get your local version of Debian's master branch mixed up with your local version of upstream's master branch.) S
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
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 git-dpm the way to drop > patches was to rebase interactively against upstream. That doesn't seem to > work with gbp pq rebase, or with gbp pq import & git rebase -i master (or > upstream). > > So how do I drop a patch with gbp-pq? The later works for me. Since there is no gbp pq rebase -i (perhaps there should be one?), this is what I do: gbp pq import git rebase -i master gbp pq export And git status shows the patch as deleted, and removed from the series file. -- Arto Jantunen
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
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 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. Thanks. I agree we should wait on this. Scott K
