by running dgit push. dgit's branches are ordinary git branches for
this purpose.
-dnstrxxx
+A downstream such as a derivative or partial derivative of Debian can
+use the dgit branches directly as the upstream for a git-based setup,
+and work entirley without source packages.
==== data flow slide
Every dgit push is actually two underlying operations: the first is a
git tag and push, to the dgit git server. The second is a
conventional package upload - with a wrinkle: the .dsc of an upload
-done with dgit contains xxxfld the git commit hash that was pushed.
+done with dgit contains an extra field with the git commit hash that
+was pushed.
Likewise, fetch and clone combine information from the archive and the
git history. If the most recent upload was done with dgit, the commit
dgit imports the source package into git - and stitches it into the
existing dgit history, if there is one.
-You do need to treat dgit git branches a bit specially is if you need to build
-source pacakges (for upload, for example). In this case dgit needs
-the .orig tarballs for your source package. If you are not doing a
-new upstream version, dgit fetch will get the relevant .origs for you.
-If you are dnxxx, then presumably you have obtained them as part of
-preparing your package, or you can build them easily.
+You do need to treat dgit git branches a bit specially is if you need
+to build source pacakges (for upload, for example). In this case dgit
+needs the .orig tarballs for your source package. If you are not
+doing a new upstream version, dgit fetch will get the relevant .origs
+for you. If you /are/ doing a new upstream version, then presumably
+you have obtained them as part of preparing your package, or you can
+build them easily.
==== NMU linear history slide
other reason why you should provide a tidy linear patch series: if the
maintainer likes quilt and is not using dgit, your changes will be
automatically presented to them in a fairly plausible format like they
-would exp xxx
+should expect from any other NMU.
An ordinary NMUer should not normally update a patch in the quilt
stack directly. Ie, an NMUer shouldn't squash their changes into an
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 directory' xxx.)
+packaging branch without .pc directory', which means that the upstream
+source files in the main package tree correspond to the actual source
+code that will be used when the package is built, rather than to the
+upstream versions.)
For all native packages, and for users of git-dpm and raw git, this is
already the interchange format. These maintainers can start using
talking to the git-buildpackage maintainers about gbp integration, so
watch this space.
-xxx slide ?
-
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 make a fake merge (with git merge -s ours) before pushing.
up. They're are relevant to maintainers and non-maintainers:
-DMs currently need to email me a signed copy of their ssh key, in
-order to be able to push. This is because the dgit repo server uses
-ssh as a transport and the project doesn't, right now, have a record
-of DMs' ssh keys.
+Firstly, some wrinkles.
+
+The first wrinkle is that DMs currently need to email me a signed copy
+of their ssh key, in order to be able to push. This is because the
+dgit repo server uses ssh as a transport and the project doesn't,
+right now, have a record of DMs' ssh keys.
-The dgit git history does not generally include the package upload
-history. git-import-dscs can produce a git branch representing the
-upload history, but dgit doesn't run that itself. why noy xxx
+The second thing that's less than ideal is that the dgit git history
+does not generally include the package upload history.
+git-import-dscs can produce a git branch representing the upload
+history, but dgit doesn't run that itself. It would be difficult for
+dgit to do so because deciding which set of versions to include is
+nontrivial and of course it would involve an awful lot of downloading.
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.
+So I think the real way to improve this is to persuade more
+maintainers to use dgit. Perhaps for maintainers who do not, we
+should at some point consider providing centrally an archive-based
+package history.
+
+
+But the most obvious challenge for a maintainer with an existing git
+branch, but trying to use dgit, is dgit's insistence that the source
+package and git tree are the same.
+
+However, some source packages contain files not in the maintainers'
+git branches, and which are needed to build: most commonly, autotools
+output. Such git branches are not useable with dgit.
+
+But nowadays most people recommend that the package build should
+always rerun autotools. 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. Merge
+conflicts etc. are easily resolved by rerunning autotools.
+
-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.
+And a second way this can bite is that 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.
-an adv co xxx
+Finally, there is one compelling advantage of dgit's git-based
+approach.
Many packages have strangely-behaved or plain buggy clean targets.
Because dgit knows that your git tree is canonical, it can help work
never have to fight a buggy clean target, in a strange package, ever again.
-wrink n
-
-Some source packages contain files not in the maintainers' git
-branches, and which are needed to build: most commonly, autotools
-output. Such git branches are not useable with dgit.
-
-But nowadays most people recommend that the package build should
-always rerun autotools. 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. Merge
-conflicts etc. are easily resolved by rerunning autotools.
-
==== Future plans slide
~ijackson / talk-2015-debconf-dgit.git / blobdiff