==== overview slide > > dgit - treat the archive as a git remote > > COLOUR 1 using dgit on other contributors' packages > > COLOUR 2 dgit for the Debian package maintainer > > Miscellany Hi. I'm here to plug dgit, which is a system for treating the Debian archive like a git remote. I'm going to talk for about 35 minutess and then I'll take questions. When we work on Debian we take on different roles. The biggest difference is between the maintainer (or maintainers) of a package, working on their own package, and everyone else. I'm going to start by presenting dgit from the point of view of everyone else: NMUers, sponsorship, teams doing cross-archive work like transitions and reproducible builds, bug squashers, downstreams, users, and so on. Maintainers, please be patient - I'll get to you. ==== data flow slide The point of dgit is that it lets everyone treat the archive as if it were a git repository. You can dgit clone any package, in any suite in the archive (so, for example, sid or experimental) and you will get a git tree which is exactly the same as dpkg-source -x. You can then work on the package in git, the way you would work in git with any other project. In particular, you can: * commit locally * cherry pick changes from other branches * git reset, git clean * git rebase -i to polish a more complex set of changes into a patch queue If you want so share your work-in-progress with others, you can git push your branch anywhere suitable, so they can fetch it. If you have the right authority you can also dgit push, to upload (after doing a build). ==== NMU linear history slide The dgit history structure is up to the maintainer. If you are doing a straightforward NMU you should produce a well-structured linear sequence of commits, as you would for any git upstream. If the source package is `3.0 (quilt)', you should not touch debian/patches; dgit will take care of that for you. ==== NMU linear history on top of basic dgit history Unless the maintainer uses dgit, the history you see in dgit will not be the maintainer's history. This is because maintainers' git branches often differ from the source packages in the archive. So dgit may have to synthesise a git history. The history you see in dgit will then have a very basic branch and commit structure, rather than representing the package's actual history. Which brings me onto the other side of this talk: dgit for maintainers. ==== history comparison slide For the reasons I've explained, downstream dgit users would like you to use dgit push. They will then be able to see, and directly work with, your own history. But it's in your own interests, too: If you use dgit, you will be able to directly merge and/or cherry-pick NMUs, patches proposed via pull-request emails, and so on: Because, in this case, the dgit-using contributor will have based their work on your own history. Using dgit for your maintainer uploads will put your own history on browse.dgit.debian.org, rather than showing dgit's stub history (which can also be out of date). If you use dgit push, you get an extra check that the source package you are uploading is exactly the same as your git HEAD. This can save you some dsc-based checks. And, as I say, non-maintainer dgit users will thank you. ==== data flow slide with EQUAL and FF dgit is not a replacement for existing git packaging tools; it's intended to complement them. So (unlike git-dpm) dgit does not define a git history structure, and (unlike git-buildpackage) it does not define a branch structure. Nor does it require a particular source format. dgit push imposes only two requirements on your git trees. These stem directly from dgit's design goals. The most important requirement is that your git tree is identical to the unpacked source package. (Technically, in the case of a `3.0 (quilt)' package, it is what is sometimes called a `patches applied packaging branch without .pc'.) For all native packages, and for users of git-dpm and raw git, this is already the interchange format. These maintainers can start using dgit right away. Please do! For those using git-buildpackage with `3.0 (quilt)', things are a bit more complicated. I'm told that gbp pq can be used to generate a patches-applied branch, and that some users prefer to use that as the interchange git branch. I'm talking to the git-buildpackage maintainers about gbp integration. The other requirement of dgit is simply that the dgit branches are fast-forwarding. So if your tools have made a rebasing branch, you may need to do something like git merge -s ours dgit/sid before pushing. I'm intending to provide some rather more cooked way to do this but I haven't decided the exact shape yet. ==== data flow slide There are a few other things I ought to cover, since they often come up. They're are relevant to maintainers and non-maintainers: DMs currently need to email a signed copy of their ssh key, in order to be able to push. The dgit view does not generally include the package upload history. git-import-dscs can produce a git branch representing the upload history, but dgit does do that itself. One could push such a branch to the archive with dgit push. But, it seems to me that the git history structure ought to up to the maintainer, and if the maintainer chooses to use dgit, the maintainers's existing git history is probably better. It is normally best to use one of dgit's build operations to build for upload. This is mainly because most other tools remove .gitignore by default. dgit requires that the source package and git tree are the same, so if your git tree has .gitignore in it, your source package should too. Many packages have strangely-behaved or plain buggy clean targets. Because dgit knows that your git tree is canonical, it can help work around this: you can tell dgit to use git clean instead, avoiding the package's clean target entirely. Some maintainers' source packages contain files not in their git branches: most commonly, autotools output. This is not compatible with dgit's purpose of providing a git view of the archive. But nowadays most people recommend that the package build should always rerun autotools, anyway. If you do that, then neither your git tree nor your source package need contain the autotools output and all is well. Alternatively, you can commit the autotools output to git. ==== Future plans slide > DELAYED uploads > > automatic sending of the NMU diff email > > one step source-only push/upload > > use of the dgit git repo server (other branches and tags) for general > purpose work > > better tooling assistance for use with raw git-rebase > > automatic mirroring into the dgit git branches of non-dgit uploads > > > help needed > > better workflow documentation for integration with existing git > tools (esp. re NMU integration and new upstream version handling). > > better gbp integration > > sponsor queue I have a number of plans for the future, some of which I need help with. But I don't have time, I'm afraid, to go through them. Instead, I'm going to open the talk up to questions now.