Hi Sean, Quoting Sean Whitton (2017-11-23 22:36:35) > Heh, sorry, I've not yet used the workflow for a real upstream that > releases only tarballs; I've only tested gbp-import-orig(1) in > artificial scenarios.
all the software I maintain indeed has upstream using git. My reason for still relying on tarballs is the software that has DFSG-nonfree material in their git repositories. I rather not deal with the legal implications and have my git repos DFSG-clean. A second reason is, that just "git rm evil.bin" seems quite error prone. Usually the DFSG-nonfree material sits in dozens of files everywhere across the project source code. The Files-Excluded in debian/copyright is a nice way to declare all paths to exclude from the upstream source. With a git-based workflow I'm on my own to store somewhere which files I want to exclude. > I think that what you are hitting is the recent change of > gbp-import-orig(1)'s default from --merge-mode=merge to --merge-mode=replace. > > For this workflow we want --merge-mode=merge, so that git-merge(1) > handles the re-application of the Debian changes for us (that's the > whole point of the workflow, after all). So I will add > > [import-orig] > merge-mode = merge > > to the recommended gbp.conf. > > If you want to test, you could just pass --merge-mode=merge to > gbp-import-orig(1). I'm afraid I cannot test that because I happened to have thrown away my old upstream branch. And with that gbp.conf, "gbp import-orig" is not doing the right thing. I suppose that's because my workaround for the missing upstream branch was to create it as a duplicate of my master branch (which has the patches applied). > > And a related side question (that maybe should also have an answer in the > > man page): What are the recommendations for the upstream branch? For "When > > upstream tags releases in git" you write "here is no need to maintain a > > separate 'upstream' branch" but does this also hold for "When upstream > > releases only tarballs"? Because if I don't push the upstream branch to > > anywhere, then the steps under "NEW UPSTREAM RELEASES" will fail because > > "gbp import-orig" doesn't see an upstream branch. So maybe the man page > > could also expand on the need for an upstream branch if upstream releases > > tarball and recommendations on where and when it should be pushed or how > > one can do without it. For example maybe the question can be answered > > whether the upstream branch can be pushed to dgit-repos or whether alioth > > has to be used for that. > > Yes indeed, you need to maintain an upstream branch if upstream releases > only tarballs. The manpage currently suggests that pushing that branch > to alioth is optional, but as you say, it is actually required in order > for future gbp-import-orig(1) calls to succeed. > > I will expand that section to say that you must push the upstream branch > somewhere; eventually dgit-repos, but until that is possible (#848678), to > alioth. I'd just like to avoid having to maintain a *second* git repository next to the dgit-repos. Isn't there a way to create a new empty upstream branch on the fly at the point where the maintainer wants to import a new upstream release? Because at that point, the maintainer did "dgit clone" and has the current upstream tarball available which could be used to set up an upstream branch with just the old upstream version in it as a single commit, no? That way, the upstream branch could be thrown away because it could be recreated every time it is needed (when gbp import-orig is run).
signature.asc
Description: signature
