On Fri, May 18, 2012 at 01:27:50PM +0200, Adam Borowski wrote: > On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote: > > Charles Plessy <ple...@debian.org> writes: > > > > > Also, it is very sad that, as a project, we can not decide whether we go > > > for 3.0 (git) or not, or have a concrete list of resolvable objections > > > from the people whose work is direclty impacted by the use of this > > > format. > > > > We know what a primary concrete objection is. We discussed it at length > > at DebConf two years ago, and then on debian-devel afterwards. Uploading > > a Git archive requires reviewing the entire contents of the archive, not > > just the current code, for licensing issues, which is pretty painful from > > the ftp-master perspective. > > How come? If the .git directory shipped in the package is pruned, there is > no hidden data. All you have to review are commits that are present there, > which is exactly the same as with quilt: you need to review the tarball and > every single patch.
I think this is a key point. The aim of the git format should not be provide the entire history, any more than the other formats do (not). What should be provided needs to be - sufficient to build the package - sufficient to determine the changes made between the Upstream release and the Debian upload - sufficient to allow further uploads, including NMUs - (allow restoration of the full history) > > There was never really a satisfactory resolution to that discussion. We > > can upload very shallow clones, but they end up looking a lot like the > > existing quilt format with single-debian-patch, > > There's a whole world between shallow clones and complete ones. While > existing git porcelain provides no convenient tools to selectively > shallowify a repository, this is because no one had that need before. > > If we allow non-linear Debian changes (ie, merged not rebased, etc), there > is indeed a complex question: where to cut[2]. But even then, a given commit > is either present or not. If too much old history is there, that's no > different from the upstream shipping an old tarball and a pile of patches > upon it (like ancient apache or qmail). If the git repo contain two tags, maybe signed, one which uniquely referenced the upstream version, and one which referenced the debian version, then all commits not part of the graph between these two commits could be dropped. This would preserve all history of branching and merging between these two points. Tools used for importing upstream tarballs could automatically create such tags; native git projects can do this themselves. These tags could be put in the .dsc, so that projects can use their own naming rules, or dpkg-source could use a specific method. [As an upstream who uses signed tags for all releases, the flexibility to use the project- specific tags would be useful.] dak could check that the upstream tag referenced the same commit between uploads, as well as maybe also verifying the tag signature. This would ensure that the upstream source couldn't be altered in an upload, the same as is enforced for orig.tar right now. dak could also check the debian tag if required; though the .dsc signature would presumably be sufficient, signed tag verification would be useful for a potential git-only workflow in the future. Providing that the packaged repo contains links to the public git repo, and we can get this from debian/control (in case the developer is using a private or git+ssh repo), the end user should be able to do a simple "git fetch origin" to restore the full history. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120518124912.gi22...@codelibre.net