We spoke today at lunchtime, and I promised to write up our conclusions.
Background: (This is all in the context of format `3.0 (quilt)'.) git-buildpackage normally works with packages-unapplied branches as the primary interchange format. dgit needs a patches-applied branch. The git history made with a dgit-based NMU will, in general, contain (a) a series of linear commits touching both upstream files and debian/changelog (but not touching debian/patches) (b) a commit made by dgit which makes corresonding patch(es) in debian/patches. 1. Pushing with dgit * Essentially, dgit replaces debsign and dput. It does all of: Tag signing, dsc signing, changelog signing, git pushing to the dgit repos, and the dput. The plan is that dgit will * Detect or be told that we're using a patches-unapplied-based tree This might be done automatically, or by explicit instruction via a command-line option, or perhaps there would be some user configuration to tell dgit whether to guess. If dgit is to guess, it will observe that the tree doesn't match the proposed .dsc if treated as patches-applied, and then try treating it as patches-unapplied. * If using patches-unapplied, dgit push will make, privately, a commit which converts the tree to patches-unapplied. It is that commit which will be the dgit push candidate. * The private commit might need to have as a parent the previous commit on the dgit branch (which wouldn't necessarily be visible anywhere else). dgit would automatically do this if it found a changelog entry in the to-push commit, which mentions the same version number as the changelog entry found in the previous dgit branch state. * If using patches-unapplied, keep the tag spaces separate between the dgit git repos and the local tree. That is, patches-applied tags wouldn't be fetched into the local tree's refs, nor would the dgit-generated signed push authorisation tag be recorded in under its actual name. Also, dgit would make a gbp-style unapplied tag, using gbp to discover the tag text that gbp would use. That tag would be made locally but not pushed to the dgit-repos. The result of all this is two separate tagging worlds, which contain tags of the same name referring to different contents. Both these tags would be signed by dgit push. The dgit infrastructure server would never mistake a non-dgit tag for a dgit one, because the dgit tags mention (and are required to mention) dgit. There would be no protection against other programs or humans mistaking one kind of tag for the other. This is all obviously not ideal. But it is difficult to see how to resolve this problem without changing either gbp, or dgit (and also presumably git-dpm), to use a different tag naming convention, which I think each of us probably would prefer not to do. We agreed to think about this some more and see if a better idea presented itself. * When a gbp user wants to incorporate an NMU, the dgit NMU history is probably not that helpful because it contains mixed-upstream-and-debian commits. However, the gbp user can use git-import-dsc on the NMU .dsc. That will contain the correct patches as the gbp user will expect, so this is the best workflow. Currently the gbp user needs to somehow arrange that they run git-import-dsc on the right branch. (Perhaps this is right be default.) It would be nice if there were some tooling, probably part of gbp, which would double check this. * .gitignore: We agree that the source package should contain .gitignore if the git tree does. (dgit requires this.) If the way that gbp does builds currently ends up with .gitignore missing from source packages, this needs to be fixed. (We didn't discuss this in detail, but: dgit has a build wrapper for gbp but it may be that this is unnecessary and users should just use gbp to build. If this is so, then at the very least the dgit documentation should deprecate the dgit gbp-build function.) * It would be good if there were documentation explaining how to use dgit and gbp together. We thought this should probably live in the gbp package. I have a bug report (#794244) against git-dpm which requests such documentation for git-dpm, which I offered to rework into a similar bug report for gbp. (I still intend do that, depending on the what you think of this summary, etc.) I think I have covered everything that we spoke about and which is in my notes. Thanks, Ian. _______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
