Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Adam Borowski <kilobyte@angband.pl> writes:
> On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote:
>> Charles Plessy <plessy@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.
And there you have hit the problem.
If the history is pruned to just the latest version then it is
pointless. All you end up is a bunch of branches without history that
randomly lack their interconnections and a master branch that again
lacks the interconnections to the feature branches. Any change to a
feature branch will likely cause a merge conflict when you try to merge
it to master because the history of past conflict resolutions is
missing.
And if you do keep enough history to preserve the interconnections
between branches then ftp-master has to review all that history.
Note: if the pruned feature branches do not cause merge conflicts then
you have a set of features that is trivialy serializable (since it has
no dependencies on the order) and your feature branches are identical to
a set of patch files. So you have gained nothing of 3.0 (quilt).
>> 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
Sorry, but if you rebase you have already lost. Rebase destroys history
and makes the commit a one-shot deal. You will not have continuity.
Rebase is something you can use internally or to create a serilaized
patch queue but not something to distribute to the world.
> 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 you manage to get your git branches serialized and rebased to the
point of shipping EXACTLY the same data as quilt would then there really
is no point of not shipping the data as quilt would. At that point you
have destroyed any benefits of git but are still forcing the much more
complex git format on people instead of a simple patch queue (which
doesn't even need quilt or quilt knowledge to use).
> 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 if we don't allow non-linear Debian changes then there is 0 benefit
from not using 3.0 (quilt) format. Once you have gotten your changes
serialized (linear) it is absolutely trivial to automatically create a
3.0 (quilt) format package from your git repository at no loss (other
than the history you were going to prune anyway). That's what for
example gitpkg does.
> 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.
It would just lead to people fighting with git.
As you say the 3.0 (quilt) problem is more a psychological issue. The
solution isn't to switch to a much more complex tool like git but to
teach people how to use the simple one. Or in this case how to remove it
from the workflow when using git.
Maintaining sources in git and producing a 3.0 (quilt) source package
with either a single debian patch or an automatically generated patch
queue gives you the best of both worlds. People familiar with git can
use the git repository and simply ignore the quilt part since it is
completly automatic. And people unfamiliar with git can use the debian
source package and send their patches to you for inclusion just like
they always could.
> [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.
Git simply removes empty dirs and suddenly sources fail to build. Also
broken.
As an excuse to quilt one has to say that quilt does not preserve the
timestamps of files not in any patch. It simply doesn't touch them at
all. And files that are patched don't get their timestamp preserved
since patch doesn't do that. This is nothing quilt does, that is saddly
just how patches work.
Not sure what you mean about empty directory, device nodes, named pipes,
etc. How is a patch going to touch those?
> [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.
MfG
Goswin
Reply to: