Hello Shengjing, On Sat, Jul 07 2018, Shengjing Zhu wrote:
> I'm not against this. My initial proposal is to keep the upstream git > history. Let me describe my initial proposal a little more. > > Branch "upstream": > This branch is same as upstream. Even there're files listed in > Files-Excluded. Let's leave these files along. > Reasons: > I think if you create a file remove commit every time, the history becomes: > > * a2cc547 (upstream) remove-nonfree > * fb0eef5 Merge commit '70d7cda' into upstream > |\ > * | 8206887 remove-nonfree > | | * 6111635 upstream-commit-f > | |/ > | * 70d7cda upstream-commit-e > | * b0218d2 upstream-commit-d > |/ > * 04a0cee upstream-commit-c > * c4f272f upstream-commit-b > * d24bf26 upstream-commit-a > > This history becomes a mess, which I don't think it's "gitish" To my mind, this history represents exactly what is going on, and that is not messy. But in any case, I think you're mistaken about the remove-nonfree commits. You will only need one of these commits when new files get added to Files-Excluded. If you `git merge` an upstream tag into your DFSG-free branch, files previously deleted will not reappear. `git merge` is smarter than you think :) See dgit-maint-debrebase(7) section "HANDLING DFSG-NON-FREE MATERIAL". > So I want the the upstream branch *only* contains upstream-commit-* > > Let's talk about `git blame`. if you blame the free files, you only > see upstream commits, that's not influenced. > If you blame on nonfree files, you will see lots of repeated remove > commits, do you really need theme? You already know these files are > remove from Files-Excluded field. > > About `git bisect`, that's interesting if the bug is caused by > remove-commits(which means caused by nonfree files). I don't think > this will happens so often. I can't really make sense of this. You seem to be describing using `git blame` and `git bisect` on upstream's git history. That has nothing to do with Debian. > However this proposal becomes unaccepted when Ian think the dgit user > case. Actually I haven't try dgit yet and I don't know if it really > doesn't work. I didn't confirm Ian's analysis, but whether or not dgit works is something that can usually be determined from the description of the workflow. You don't need to actually try it. > Because maybe dgit users can't generate the dfsg tarball, after they > clone from VCS-Git address. However my proposal it to let gbp be able > to generate the dfsg tarballs even the nonfree files are in upstream > branch. And you can still commit these dfsg tarballs into pristine-tar > branch or other places. Generaly comment: if you're using a dgit workflow tarballs are an implementation detail. -- Sean Whitton
