From 78a6c4bf1accae662fc7bdb18c3f3db4f493cbca Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Sat, 28 Jul 2018 05:08:09 +0100 Subject: [PATCH] talk changes apropos email from sean --- talk.txt | 75 ++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 49 insertions(+), 26 deletions(-) diff --git a/talk.txt b/talk.txt index 614eb03..df773c2 100644 --- a/talk.txt +++ b/talk.txt @@ -27,18 +27,26 @@ Debian version of a package you maintain. git-debrebase helps you maintain a useful git branch with the contents you need (for building and uploading). -It maintains your Debian delta queue - that is, that is, the changes -you make, for Debian, to the upstream parts of the package - as a -series of commits. It's primarily intended for Debian package -maintainers, although you could use it outside of or alongside Debian. +git-debrebase is mainly concerned with maintaining your Debian delta +queue. That is, that is, the changes you make, for Debian, to the +upstream parts of the package. Other tools tend to call this your +"quilt patch series". But with git-debrebase there is no quilt, and +you don't work with patches. Instead, there is a series of commits. +So, we prefer the term "delta queue". + +It's primarily intended for Debian package maintainers, although you +could use it outside of or alongside Debian. git-debrebase does not deal with building at all. You use whatever your existing build tools are. Nor does git-debrebase deal with source packages or orig tarballs. It does not do uploads. Of course when you actually upload to Debian you -need to produce a source package; usually, this would be done -automatically for you by dgit push-source. +need to produce a source package. Getting a source package is, of +course, as easy or easier than with other workflows. Usually, it is +done automatically for you by dgit push-source, so you usually don't +need to concern yourself with .dsc source packages even when uploading +to Debian. Of course you can share your git branch on a service like salsa, without building or uploading. @@ -46,9 +54,11 @@ without building or uploading. ===== usp slide 1 git-debrebase offers a standard git-rebase workflow, where you edit -the whole package all together. The experience is very like using -plain git-rebase to edit a topic branch. Delta queue editing can be -done at any time, interleaved with packaging work. +the whole of the source code for your package, including your changes +to upstream files and your changes to packaging, all together. +The experience is very like using plain git-rebase to edit a topic +branch. Delta queue editing can be done at any time, interleaved with +packaging work. As far as I know there are no other tools that offer these features. Both gbp pq and git-dpm require you to switch to a separate view in @@ -69,9 +79,13 @@ files. Of course you can always directly edit the source if you use a plain git merge workflow and non-quilt source package - for example, as described in the dgit-maint-merge tutorial manpage. But of course -that does not maintain the Debian delta as a broken-down series. -Supporting you maintaining such a delta queue is what git-rebase is -for. +that does not maintain the Debian delta as a broken-down series; +and in the source package such a merge based workflow squashes all the +changes into a single debian-changes patch. + +So supporting you maintaining a delta queue - that is, a linear series +of changes - is what git-rebase is for. + Also, unlike git-dpm and some other tools, git-debrebase has no in-tree metadata, so it can't get out of date or be desynchronised, @@ -83,18 +97,19 @@ As I said, unlike with gbp pq and git-dpm, there is no need to ever switch branches. git-debrebase only uses one branch to handle all for your Debian work. -Of course usually you will have an upstream remote tracking branch as +Of course usually you will have an upstream remote-tracking branch as well. And if you are working in multiple Debian releases, backports for example, you will have branches for those. But it's only one branch for each line of Debian development, and no temporary branches or alternative views. -With git-debrebase, yowr working tree is always immediately buildable -with dpkg-buildpackage (or whatever other build tool you prefer). And -it is never made dirty by git-debrebase or any of the other tooling: -Because your working tree always has the delta queue applied, it is -never dirtied by patch application. Because there is no metadata, you -can never get a metadata conflict. +With git-debrebase, you can always immediately build binaries out of +your working tree, with dpkg-buildpackage (or whatever other build +tool you prefer). And your working tree is never made dirty by +git-debrebase or any of the other tooling: Because your working tree +always has the delta queue applied, it is never dirtied by patch +application. Because there is no metadata, you can never get a +metadata conflict. Because git-debrebase treats the quilt patches in debian/patches/ as an output, and handles them entirely automatically, your tree is never @@ -110,6 +125,7 @@ With git-debrebase, git-blame, and git-log on a file, work entirely properly. For example, if you do git-log on a file from upstream which was changed in the Debian delta queue, git-log will show the Debian delta queue commits, preceded by the upstream history. +We'll show an example of this in the demo. If you run git-blame you will see a correct indication of which upstream and/or delta queue commits introduced each line. Or, for a @@ -117,9 +133,14 @@ file in the debian directory, you will see a correct reporting of which commits in the package's packaging history introduced each line. With git-debrebase, you never need to use the quilt program. You can -mostly ignore the 3.0 quilt source format. Unfortunately it is not -possible to paper over the cracks completely: you will still get -trouble if you make changes in git which 3.0 quilt cannot represent. +mostly ignore the 3.0 quilt source format. + +This is all really good for newbies. Particularly, for people from +other sofware development communities who don't know about Debian. + +Unfortunately it is not possible to paper over the cracks completely: +you will still get trouble if you make changes in git which 3.0 quilt +cannot represent. On the other hand, when you use git-debrebase with 3.0 quilt, the generated 3.0 quilt source package is perfect pretty, with your delta @@ -233,8 +254,9 @@ ask for an interactive rebase, and there are no merge conflicts, that's it as far as the code in git is concerned. Of course if you are going to upload to the Debian archive you'll also -have to make an orig tarball of the new upstream. There are tools -like git-deborig to help with that. +have to make an orig tarball of the new upstream. If you're using the +workflow I've been describing so far, that's generally just a single +call to git-deborig. ===== data model slide up to PM [5] @@ -305,7 +327,8 @@ fast-forwarding branch suitable for pushing to salsa or whereever. More common is a different kind of merge problem. What happens if you one of your delta queue commits doesn't apply -during the upstream rebase ? +during the upstream rebase - that is, your patch does not apply to the +new upstream source code ? git-rebase users will have seen this kind of situation before. git-rebase stops at the first commit which can't be applied in @@ -330,7 +353,7 @@ can just say git rebase --abort and everything just gets put back. The autogenerated special breakwater merge, and changelog entry, are discarded, leaving you just where you were before. You've wasted no -effort because everything you're throwing away was machine-made. +effort because everything you're throwing away was machine-generated. ===== data model slide [5] AGAIN -- 2.30.2