Nish Aravamudan writes ("Re: DEP14 policy for two dots"): > On 09.11.2016 [23:38:30 +0000], Ian Jackson wrote: > > Can you confirm what approach you have taken to the representation of > > Debian source packges as git trees ? I would like to encourage you to > > use a representation which is compatible with dgit. > > I think we are fairly compatible. The only difference would be the > actual git commits themselves, I think, because we treat Launchpad as > our canonical source of information, while dgit uses the Debian archive > (aiui).
dgit can work on Ubuntu too, in a readonly mode. (It would be nice to make `dgit push' work on Ubuntu but that requires a suitable git server, and some configration on the dgit client side.) > > That is, the git tree object should look exactly like the results of > > `dpkg-source -x', except that the .pc directory which dpkg-source > > creates for `3.0 (quilt)' packages is deleted. > > Yes, we use `dpkg-source -x --skip-patches` on an appropriate DSC file > for both Debian and Ubuntu publications. That is the tree we commit with > appropriate parents (as determined by Launchpad's publication history > and the d/changelog file). The --skip-patches is a vital difference. Has the decision to use --skip-patches been definitively taken ? I would like to beg you to reconsider this, in the strongest possible terms. --skip-patches generates a patches-unapplied tree. A patches-unapplied tree: * produces confusing and sometimes misleading output from git grep, or (even if appropriate history is available) with git blame; * cannot be used with `git cherry pick <some upstream bugfix>'; * cannot be used as a basis for `git merge upstream/<whatever>'; * requires that the user not say `git diff upstream/master' but rather that they read patches in debian/patches; * cannot be directly edited by the user; * leaves the git tree dirty after every build with dpkg-buildpackage no matter how careful or tidy the package's build system. For these reasons, dgit's interchange format is patches-applied trees. (dgit 2.x supports a maintainer using patches-unapplied branch and converts it for publication during dgit push.) I understand why many Debian maintainers like to use patches-unapplied trees. They make a reasonable archival format for a maintainer who: - understands the `3.0 (quilt)' format very well; - understands their own quilt/git workflow; - has chosen to use (and to learn) a specific Debian git workflow tool such as git-buildpackage; - is willing to read interdiffs occasionally. These are not properties we should expect of all our users and downstreams. They are not even properties we should expect of all our future developers. dgit (and git-dpm) show that it is possible to work with, and interchange, patches-applied git trees. > > It would probably be nice if the commit history structure of imported > > source packges was a bit like the dgit imports. Or better if it were > > identical, but that's probably too much to ask for because you > > probably do not want to make dgit 2.x a dependency for your project. > > I will spend some time next week looking at what dgit imports look like, > but I'm guessing they are not the same currently. If you are making patches-unapplied trees I think you cannot possibly be representing the quilt patch stack of a `3.0 (quilt)' source package as a series of git commits. Representing a `3.0 (quilt)' package that way is desirable, as it means that `git blame' and `git log' can be used to see which patches do what. > > I encourage you to try out dgit 2.x and see what you think of its > > efforts for some existing source packages. Eg `dgit clone libvirt > > stretch'. > > I will do this soon, to compare, thanks! The dgit_2.11_all.deb binary package in Debian unstable is very likely to be directly installable and useable on all supported Ubuntu versions. So I think you can just `dpkg -i && apt-get -f install' (or apt install ./dgit.deb, if your apt can do that). Anyway, thanks for your consideration of my points, above. Regards, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter. _______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss