Hello Johannes, On Fri, Nov 24 2017, Johannes Schauer wrote:
> 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. Yes, this is reasonable for packages with lots of DFSG problems. > 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? I'm not sure whether or not something like this could be done. It breaks assumptions of gbp-import-orig(1), which expects an upstream branch always to be present. I understand your desire to avoid a second git repo, but I don't want to incorporate that into the manpage. I want to keep the usage of gbp-import-orig(1) as straightforward as possible, and that requires pushing to alioth. I think you'll find that you will want to push to alioth anyway, for WIP commits between uploads. -- Sean Whitton
signature.asc
Description: PGP signature
