On Tuesday 18 August 2015 11:15:17 Joachim Breitner wrote: > Hi, > > this is a follow-up to my question after the dgit talk today: It would > be great to have a git view of the a package’s history in Debian. There > is some possible overlap with dgit in the sense that if everyone had > been using dgit from the start, then we would have that, but dgit’s > objectives are slightly different, so maybe my question could be posed > and answered separately. I had the same thought: - It's simple, easy to understand - No need for a separate tool - It's enough for many use cases > SNIP > * 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 > * 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. The tag name should be namespaced with the package name to allow different packages to coexist in one repo. Advantages: - No need to think about the right ordering - Problematic versions can be removed any time - Users can fetch just one specific tag without downloading other versions. This might make a difference with packages with lots of binary data. > These rules should, unless suddenly new historic packages appear, > ensure that we get identical git hashes if we re-run this tool, > which is goo. This is not an issue with my proposal above. > * 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 > * Optionally: One tag per version pointing to the corresponding > commit, for each version. Although maybe that would produce too > many tags... :-)
Attachment:
signature.asc
Description: This is a digitally signed message part.