Ian Jackson <[email protected]> writes: > Dima Kogan writes ("Bug#1124338: dgit: dgit is confused by merged branch with > debian/"): >> Hi. Thanks for replying. I did read the docs, and the "maint-merge" >> workflow is what I'm pretty sure I want. > > dgit-maint-merge(7) works with a patches-applied branch. > Your existing "gbp" branch is presumably patches-unapplied.
Hi. I want to move from patches-unapplied gbp to a patches-applied plain-git thing. I've already done this for a few of my packages with great success, but this one doesn't work. I thought I understood why, but I just poked at it again, and I don't know why. I am also upstream here. Which means that most of the time there will be no patches, or a very small number. RIGHT NOW there are a few patches: I fixed a few small things since the last release, but haven't made a new release yet. > dgit by default expects your branch to be patches-applied, but with > possible local changes to upstream files added on top in commits. > It is trying to find those commits so that it can turn them into > patches in d/patches. That's exactly what I want. > Your existing branch would work with --quilt=gbp, probably. The > default, --quilt=linear, is simply wrong in this case. OK... after I combine the upstream tree and the debianization (via a merge of rebase of whatever) I will have a patches-applied repo, so --quilt=gbp is 100% not the right thing. Right? Is --quilt=linear also not the right thing? If you have a moment to look at the specific failing thing, could you do that? Would clarify the situation for everybody, and would really help me. Recipe: gbp clone --debian-branch=dgit-test-deb-patches-merged [email protected]:science-team/mrcal.git cd mrcal git checkout dgit-test-deb-patches-merged origtargz This is a merge of the latest upstream git tag (v2.5) and a debian branch. Then there's a commit to remove all the patches. This should be the nominal case: there are no debian/patches and the tree and clean and no extra commits exist. dgit should be fine, with nothing to do: dgit --clean=git --quilt=linear quilt-fixup This is as expected: looks at stuff, and happily does nothing. Same with --quilt=gbp. I merge in the latest upstream. This isn't released yet, but has a few small patches I'd like to be quiltified: git remote add upstream https://github.com/dkogan/mrcal.git git fetch upstream git merge upstream/master All good. Here --quilt=gbp fails since this is patches-applied. --quilt=linear squashes the commits into one, however: dima@shorty:/tmp/mrcal$ dgit --clean=git --quilt=linear quilt-fixup Format `3.0 (quilt)', need to check/update patch stack examining quilt state (multiple patches, linear mode) dgit: base trees orig=e949c82c22e8bc6e803a o+d/p=e949c82c22e8bc6e803a dgit: quilt differences: src: ## orig == gitignores: == orig == dgit: quilt differences: HEAD ## o+d/p HEAD == o+d/p starting quiltify (multiple patches, linear mode) quiltify linearisation planning successful, executing... Commit Debian 3.0 (quilt) metadata [dgit (12.8) quilt-fixup] [master 6b56ef91] Commit Debian 3.0 (quilt) metadata 2 files changed, 424 insertions(+) create mode 100644 debian/patches/merge-remote-tracking-branch-upstreammas.patch create mode 100644 debian/patches/series Other dgit trees I've used figure out how to do one-commit-per-patch. I think this is the normal way to be doing this, right? I'm not trying to do anything weird and non-standard. I had another earlier attempt that was complaining about the old debian/ stuff in the upstream tree, hence the title fo this bug. I'm now thinking that's probably a red herring. Thanks for the help.
