On Tue, Feb 17, 2015 at 10:09:16PM +0200, Markus Lehtonen wrote: > 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.
There were two things I didn't like about the svn workflow for Debian packages. debian/ and upstream source not in one tree (so I can not build with a patched package easily to try fixes) and having to use an export dir (slowing down the build and not giving me a single source tree to grep through). It seems that having the packaging separate brings back these two things some I'm opposed but maybe there are good arguments in favour of just omitting the merge and putting debian/ into the upstream tree? If we create a fake merge commit it's even easy to see where the upstream source came from. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
