On Thu, Jul 5, 2018 at 7:51 PM Ian Jackson <ijack...@chiark.greenend.org.uk> wrote: > My objective here is to publish to the Debian user the source code of > the package they are using. > > If upstream are using git, then the user should get a git branch which > contains the upstream history. >
I'm suspect if you really need upstream git log in the scenery you described. What you really care is the packaging history. > But obviously the user who asks for the source code for their Debian > package must not get the nonfree files. They still get nonfree files. It contains in the history. If the nonfree files are large blob, users still waste traffics to clone the repo. That's why I'm saying " It's git, you're cheating youself to remove something." I think you may misunderstand why I refer uscan here. When this discussion started long ago, uscan can't import upstream git HEAD version. But now it supports. Why uscan is related here, because it supports Files-Excluded, and is integrated with gbp. You can use `gbp import-orig --uscan`, to import upstream git HEAD version(eg, 0.0~git20180705.abcdefg), with nonfree files excluded. This results a familiar repository, and is compatible with dgit. I'm using this work flow several times. It works fine. But the only disadvantage is, I lost the upstream git log. For example, I want to cherry-pick something. So my perspective is from the maintainer, not the user. So I start thinking keeping upstream log, and only generated dfsg tarball. There's no need to waste space to keep another dfsg branch, with some chaos git commits. Users are still able to dget dsc; or if they like, gbp clone, and gbp buildpackage. However, if you really care dgit user. I may ask, what you want the dfsg branch looks like? Do you prefer full upstream log, along with some `git rm` commits; or like one import commit per release version? If it's latter, maybe it can be easily regenerated with all orig tarballs.-- Best regards, Shengjing Zhu
