[Dropping Peter from CC] Hi, Am Dienstag, den 18.08.2015, 15:22 +0200 schrieb Thomas Koch: > > > * Every source package from snapshots.d.o becomes, extracted with > > dpkg-source -x as usual, produces a git tree object. > > I’d probably simply ignore empty directories. > Please add a trailer line in the commit message that can be used as argument > to mkdir -p to recreate the directoriesl My current code creates a tree object tagged with the version number, and defers the creation of the commit objects till later, without access to the unpacked source, so this feature requires a way to carry over that information. I could ofcourse force an empty directory into the tree object, following http://stackoverflow.com/questions/11600871/git-repo-contains-an-empty-directory-what-happens/11600882#11600882 unfortunately git does not cope well with that. I’ll think about it. > > * Every source package also produces a git commit, with > > - Tree: the above > > - Author: top changelog entry > > - Date: also top changelog entry > > - Description summary: The version number > > - Description text: The top changelog entry. > > - Parents: This is the interesting bit > > The set of parents should be the commits corresponding to any > > version mentioned in debian/changelog, pruned by those that > > are transitively reachable. > > > > This ensures that we get a nice git DAG for things like packages > > that have been experimental for a while, merging from unstable > > repeatedly. > > > > The order of parents could correspond to the order in > > debian/changelog, so that the second changelog entry becomes > > the first parent. > > Since you see the complication: Why not have no parents at all? Just have tags > that point to orphan commits. One can still use diff. If you should need a > branch for some reason (I doubt) than have a tool to order the tags with dpkg > --compare-version and write new commits that form a branch. I really like to have a DAG that represents the history of the package, and I don’t think it is a big complication. The bug tracker does it also this way, I believe, to produce these nice graphs in the corner. Also, "git merge-base --independent" does the heavy lifting of this logic for us. > Advantages: > - No need to think about the right ordering I’m willing to think :-) > - Problematic versions can be removed any time I’m willing to have the commit id changes in this case. > - Users can fetch just one specific tag without downloading other versions. > This might make a difference with packages with lots of binary data. You can still use "git clone --shallow", can’t you? > > * Every suite (unstable, jessie...) becomes a branch, pointing to the > > corresponding commit > Just encode the suite in the tag name: PACKAGE/SUITE/VERSION: > libcgi-application-plugin-authorization-perl/experimental/3:5.4_g424242+5-2bpo That does not look right: Either I want the version in experimental, or I want a specific version. Also, how do you get backports versions into experimental? ;-) Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part