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.
> 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.
For example, if you limit yourself to a bunch of linear rebased commits atop
of the newest upstream tag, you can exactly emulate quilt workflow except
for not having to deal with quilt's peculiarities. This goes to the point
of shipping EXACTLY the same data as quilt would, with only metadata
different[1]. And unlike what you say, commits are not flattened in any
way.
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).
And besides, what's the reason behind enforcing exactly one upstream and
exactly one "Debian"? This just leads to problems if either side has
multiple layers.
> and it's not horribly
> clear what the advantages of 3.0 (git) are at that point. Many of the
> really compelling use cases for 3.0 (git), neat stuff like possibly being
> able to just push a signed tag instead of uploading or having the package
> history when you get the source package, aren't very interesting with
> shallow clones.
It's more a psychological issue: while you can use 3.0 (quilt) to emulate
1.0, people don't know about that. Even though 6500 of packages in Debian
store their packaging in git, they typically fight with quilt, while that
shallow copy = single-debian-patch would at least remove that concern.
[1]. Git keeps references to commits not present in the shallow repository.
3.0 (quilt) in turn partially and inconsistently preserves timestamps, but
only on files that haven't been modified in any of the patches. Also, the
tarball may ship an empty directory, device nodes, named pipes, etc --
again, only as long as no patch touches them.
[2]. One way: cut all commits which don't have one of current upstream
"tarballs" as an ancestor. This can sometimes cut more than one would want,
but is strictly better than a shallow copy.
--
“This is gonna be as easy as cheating on an ethics exam!”
-Cerise Brightmoon
signature.asc
Description: Digital signature
