On Thu, Jul 5, 2018 at 6:19 PM Ian Jackson <ijack...@chiark.greenend.org.uk> wrote: > If you are using a gitish workflow, I don't think the Files-Excluded > should affect only the .orig. Rather, there should be a > dfsg-laundered git tree or branch too. > > For examples of how we-the-dgit-maintainers suggest users do these > things, have a look at these workflow docs: > > > https://manpages.debian.org/stretch/dgit/dgit-maint-merge.7.en.html#HANDLING_DFSG-NON-FREE_MATERIAL > > > http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git-manpage/dgit.git/dgit-maint-debrebase.7 > [search in page for "HANDLING DFSG-NON-FREE MATERIAL"] >
I haven't been a user of dgit before. So if I understand correctly, it suggests do a `git rm` commit after every release. That sounds weird to me. It's git, you're cheating youself to remove something. And there's no clean upstream log, which I think it's no better than uscan git mode. With uscan git mode, you can track upstream version, and import lastest master version. > > I write a POC patch[1] to gbp to teach `gbp export-orig` to read > > d/copyright and filter out files in Files-Excluded when running > > `git-archive`. > > Please don't do this. This workflow is not compatible with dgit. > That means the maintainer who uses that, cannot use dgit. > Yes, it's only compatible with gbp user. > What I really care about is that this means that users cannot get a > sensible git history for packages done this way. Maybe from this point, uscan is enough now? -- Best regards, Shengjing Zhu
