Guido Günther writes ("Re: Intent to commit craziness - source package unpacking"): > Hi Ian,
Hi, thanks for your attention. > From what I understand the format to produce is not compatible in what > "gbp pq" currently expects, that is just one commit per patch without > any chnages to other files in debian/ (like the series file). 'gbp pq' > is just a helper for handling the quilt patches, not more. Ah. You have spotted a bug in my proposed algorithm, which is that it would include the successive changes to the series file in the per-patch commits. That was not intentional and I will make sure my actual generated commits don't look like that. > I don't understand yet how you expect the actual workflow between gbp > and dgit to look like but I would be happy to have a look at a prototype > dgit created history. I can e.g. imagine telling "gbp pq" to filter out > chnages in debian/ during patch creation. Excuse me if I digress into some background. You may know all this but if you don't you may become confuse: There are two relevant parts of the gbp/dgit workflow: let's call them "push" and "pull-dsc-import". "push" is where a gbp-using maintainer (or someone with an appropriate maintainerish hat like a QA uploader) uses "dgit --quilt=gbp push". In this case, dgit will produce a dgit-compatible patches-applied branch out of the patches-unapplied tree provided by the user. This is done by actually calling gbp pq import. The resulting branch is `private' in the sense that it is published to the dgit server, but not left on the maintainer's own branch. (There is a wrinkle with .gitignore. If the maintainer edits an upstream gitignore, gbp's default behaviour is to exclude those changes from the source package upload. This is not compatible with dgit's model; so in this case dgit will generate a new patch to represent the .gitignore changes. There will be a new commit on the dgit view branch which adds that patch and the corresponding series file entry.) The "pull-dsc-import" case is where a gbp-using maintainer deals with an upload done by someone else who didn't use dgit push. The gbp-using maintainer does not need to use dgit for this. If they like, they can import the source package however they did this before dgit came along. The resulting maintainer branch can then be used with "dgit --quilt=gbp push" just as before, although depending on the git history the maintainer built, the maintainer might need to say "dgit --overwrite --quilt=gbp push" to reassure dgit that the maintainer is intentionally replacing the version in the archive. However, I think dgit could make this easier for the maintainer. If the maintainer uses "dgit fetch" it will fetch the source package from the archive and convert it to a git branch. That is the "dgit created history". Right, that's the end of the background. This history will (usually) have a pseudomerge at the top, making it fast forward from the dgit view branch generated during the maintainer's last "dgit push". Then (looking deeper into the history) it will have the dgit-generated patch commits, one for each patch. (Maybe there will be the .gitignore patch on top of those - see above.) These commits will in fact NOT touch anything in debian/. Then will be the base commits for the tarballs and the debianisation. Graphically: dM pseudomerge ,'| ,' | ,' dM final patch u/s only ,' | <archive/debian/X] ,' dM some patch u/s only pseudomerge dm ..... ,'| dM first patch u/s only ,' | | ,' | dM Debianisation creates[1] ,' | | debian/* ,' | | ,' | dM Upstream [2] creates u/s[1] previous | dgit view | history dm .gitignore fixup d./patches/* [3] | (create patch to only | create /.gitignore) | dm apply final patch us/only | dm apply some patch us/only ..... dm apply first patch us/only | | <debian/X] m final patch made by maintainer /|\ [whatever] Commits made by: m - maintainer before previous push dm - maintainer's dgit during previous dgit push dM - maintainer's dgit during dgit fetch; constructed from non-dgit-pushed source package (Here "maintainer" means someone using gbp and sharing history with the other maintainer(s).) [1] Of course if the upstream contains a debian/, then that will be present in the upstream tarball and will be replaced in Debianisation. [2] Mostly, imports of the same u/s tarball will generate the same commit, so this commit might be the ancestor of a previous non-dgit upload. [3] Usually the previous dgit view history will have been made by the maintainer's dgit from previous maintainer dgit pushes, in which case it will have as ancestor previous maintainer views. There is another possibility, which is an NMU made with dgit, by an NMUer who isn't using gbp. (For these purposes again, a "non-maintainer" is someone who is not using gbp and isn't sharing git history with the maintainer(s).) I'm going to illustrate work done by someone who restricts themselves to the kind of minor changes an NMUer might expect to make in Debian: <archive/debian/Y] dn NMUer's upstream | changes made d./p./* if there | into patch(es) d./p./series are multiple | maybe multiple NMUs this may | patches created be repeated | n NMUer's git commit | maybe changes to any | u/s files, maybe not (mixed) ... n NMUer's git commit | maybe changes to any | u/s files, maybe not (mixed) | <archive/debian/X] | pseudomerge dm ,'| ,' | ,' | ,' dm .gitignore fixup d./patches/* ,' | (create patch to only ,' | create /.gitignore) previous | dgit view dm apply final patch us/only history | [3] dm apply some patch us/only ..... dm apply first patch us/only | | <debian/X] m final patch made by maintainer /|\ [whatever] Commits made by: m - maintainer before previous push dm - maintainer's dgit during previous dgit push n - NMUer, directly, using git commit or whatever dn - NMUer's dgit during their dgit push [3] as before. > > An example of such a tree might be, "split out the patch queue part of > > the git pseudohistory and feed it to gbp-pq, asking gbp-pq to > > regenerate the source package, and expect the output to be identical > > to the original input source package". Guido, if I get the > > preconditions right, should I expect such a test to pass ? Is there a > > risk it would break in the future due to changes in gbp-pq's > > conversion algorithm ? > > It would be nice to have "gbp pq" reproduce debian/patches identically > on such a tree but I would rather have a look at how the dgit created > history finally looks once you implemented it. I'll send you an example. > gbp-pq's conversion algorithm is not expected to change (at least in > the default configuration, I have some other ideas about patch > handling but that would not modify the current workflow ) I had a look at what gbp pq made out of some of the commits in some of my tests and was surprised to see it dropping the commit messages. I see there's another mail from you which I will go and read now... Thanks, 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.