Hi, On 18/02/15 09:43, "Guido Günther" <a...@sigxcpu.org> wrote: >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: >>>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).
Good to hear arguments why this is not supported. My understanding is that having source code changes is not possible in the 3.0 (quilt) format. Thus, trying out fixes requires usage of gbp-pq, anyway. Please correct me, if I'm wrong. >It seems that having the packaging separate >brings back these two things some I'm opposed Basically, yes :( Would you oppose making this an optionally supported mode, if the maintainer so chooses? It shouldn't require too many changes, e.g. probably making pq-import to apply patches on top of the upstream version instead of the tip of the packaging branch and making gbp-buildpackage to export upstream-tree + packaging-branch instead of just packaging-branch. Also, I have some ideas how to enable building without having to use a separateexport directory in this mode. I think I'd need to try it out and post a conceptual patch for comments. >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. Were you thinking about 3.0(quilt) format here? IMO, this sounds better than the original idea. I've had similar ideas, but for the pq-branch, i.e. making it possible to do builds directly in the pq-branch. But again, I think I need to think about it a bit more and probably send a proof-of-concept patch for comments. Thanks, Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
