Hi Sean, On Sat, Jul 7, 2018 at 3:55 PM Sean Whitton <spwhit...@spwhitton.name> wrote > > I'm suspect if you really need upstream git log in the scenery you > > described. What you really care is the packaging history. [...] > > 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. > > It is useful to provide the full upstream git history to users because > they can use tools like `git bisect` to figure out how to fix bugs. The > packaging history alone is much more coarse grained.
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" 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. 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. 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. -- Best regards, Shengjing Zhu
