On Mon, Jan 09, 2017 at 02:02:34PM +0000, Ian Jackson wrote:
> Robie Basak writes ("Re: patches-applied historical imports (usd import)"):
> > On Mon, Jan 09, 2017 at 01:45:52PM +0000, Ian Jackson wrote:
> > > Ideally you and I could agree on a commit structure for the imported
> > > packages, and metadata processing rules, so that the commits are
> > > identical (not just the trees).
> >
> > By "commits are identical", are you including parent commit hashes? Or
> > just everything else?
>
> It's true that not all of the parent hashes could be identical.Right. In particular, our importer has two sources of input for the unapplied branches: archive history, and rich history supplied by developers. Commits generated by the importer end up having parents from both of these sources (subject to source availability). The rich history input source breaks the "reproducible commit hash" invariant somewhat. If identical rich history is available on re-import then the importer should produce the same result commit hash, but the timing of supply of the rich history affects things. For example, if an uploader forgets to give us some rich history but supplies it months later, we still want to keep it but it will not have been adopted into the graph of commits by the importer. But the importer would take it on a re-import, thus mutating all subsequent commit hashes. Right now, we're accepting rich history only for Ubuntu-specific commits. I don't think we have really considered yet what would be best for Debian. But in the future, if Debian is interested in the same mechanism, then the same would apply to Debian's ancestory trees. I don't see any reason why it wouldn't make sense for Debian to do the same thing here. The applied branches (created on your request) has the unapplied branch as a parent (sort of like git-dpm does), so the same non-reproducible-ness filters through. > dgit imports orig tarballs in a way that is supposed to produce a > stable commit hash for each tarball, so that different revisions of > the same upstream version have the upstream as a common ancestor. > > Does Nish's importer try to generate a fast-forwarding upstream > branch ? If not then part of the imported commit structure could be > the same. I believe it does currently, unless Nish steps in to correct me. So this part could indeed be the same. However, I think the same rich history case above applies here too. We're not doing it right now, but if a maintainer wants to supply rich upstream commits (for example by connecting upstream's VCS to the commit graph), then I think this is something the importer could support. And in this case, the commit hashes would start to mismatch. Robie
signature.asc
Description: PGP signature
_______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
