Hi, On 17/02/15 20:05, "Guido Günther" <a...@sigxcpu.org> wrote: >retitle 778594 gbp import-orig: allow to ignore changes outside of debian/ >severity 778594 wishlist >thanks > >On Tue, Feb 17, 2015 at 11:39:34AM +0100, Martin Pitt wrote: >> Hello again, >> >> Martin Pitt [2015-02-17 9:55 +0100]: >> > Ah indeed, most upstream updates have a "Merge tag 'upstream/XXX' into >> > experimental" after "Imported Upstream version XXX", but 217 doesn't. >> > Probably I already had some trouble with this in 218, as curiously the >> > 218 update has two identically-looking commits 99af89298 and >> > f47781d88. >> > >> > So I suppose something went wrong with importing 217. >> >> Mystery resolved. This happens when you git-import-orig a new release, >> then hack on the branch to port patches, resolve regressions, update >> packaging etc., and do a "git rebase -i origin" to clean up your work >> before pushing. That drops the above "Merge tag ... into ..." >> commits, and thus they disappear from the history. > >Yeah, see the footnote in my initial reply. Since the commit message >looked fine I assumed that this was caused by a rebase. Thanks for >confirming. > >Nevertheless a > > gbp import-orig --force-overwrite > >that produces the new upstream tree + the debian/ tree as new content >of the packaging branch should be added therefore let's move this to >wishlist.
How about an (additional) mode where no source is present in the packaging branch? That is, only have the content of the debian/ directory. No difficulties with merges and cleaner git history overall. We this kind of support in the still unmerged buildpackage-rpm tool. This mode might have the limitation of requiring a build in a separate build area (with --git-export-dir), or then some clever tricks could be done in the Git work tree to allow build in-place. Thanks, Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
