Hi Martin, On Tue, Feb 17, 2015 at 07:33:20AM +0100, Martin Pitt wrote: > Package: git-buildpackage > Version: 0.6.22 > > Hello, > > We use git-buildpackage to maintain the systemd Debian package. I was > just trying to import a new upstream version into the experimental > branch, which fails: >
Gbp basically just uses 'git merge' to merge the upstream branch into the packaging branch: [..snip..] > > Now "git status" shows a huge unresolved mess. > http://paste.debian.net/150285/ has the full output, but it looks > like this: > > | Changes to be committed: > | > | modified: README > | modified: catalog/systemd.catalog > | modified: catalog/systemd.fr.catalog > | new file: catalog/systemd.pt_BR.catalog > | [...] > > These are alright. > > | Unmerged paths: > | (use "git add/rm <file>..." as appropriate to mark resolution) > | > | both modified: Makefile-man.am > | both modified: Makefile.am > | both modified: Makefile.in > | both modified: NEWS > | both modified: TODO > | both added: catalog/systemd.pl.catalog > | both modified: config.h.in This is to be expected since version 217 was imported to 'experimental' without merging from branch 'upstream'. Commit a05fbd0f2be05e61037dc57d239a436f651519fe only has a single parent [1]. So 'gbp import-orig' would import the new tarball to 'upstream' and then notice that lots of files were modified on both 'experimental' and 'upstream' therefore your conflicts. 215 was imported correctly btw. > > (lots more) > > | Untracked files: > | (use "git add <file>..." to include in what will be committed) > | > | src/analyze/analyze-verify.h~HEAD > | src/analyze/analyze-verify.h~upstream_219 > | src/resolve/dns-type.c~HEAD These look like outputs from a merge helper, little gbp can do about it. > > (lots more) > > Before the import-orig, experimental and upstream branches were > identical (except for debian/ of course). But they didn't share a common history so git interfered that it shouldn't just overwrite the changes done on master. > I'll resolve these manually (i. e. rm everything, unpack the > tarball, then git add everything), so the branch on alioth will > probably be ahead when you look at this, so I tar'ed up the local > checkout and put it on > If you keep things as a merge commit things will work as expected from there on. We should probably just add a mode where 'gbp-import-orig' just replaces the packaging branch (experimental) with the content from the upstream branch and only keeps the debian/ treeish since with 3.0 (quilt) one usually doesn't have any modifications outside of debian/. If this sounds reasonable (and you aggree with the above anaylsis) then I'll go ahead and turn this bug into a wishlist bug with the above feature, o.k.? Cheers, -- Guido [1] or maybe 217 got imported correctly but then rebased? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
