Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)
On Thu, Sep 19, 2013 at 11:31:32AM -0700, Russ Allbery wrote:
> Ben Hutchings <ben@decadent.org.uk> writes:
>
> > Of course unreachable objects should be pruned from a 3.0 (git) package.
> > But I believe the FTP team's concerns are about *reachable* objects that
> > may be copyright violations. It is hard enough to check this for one
> > version.
>
> I think Adam's point is that there's a one-to-one correspondance between a
> 3.0 (quilt) package and a 3.0 (git) package that consists solely of an
> import of the most recent upstream source plus one commit per patch.
You can trim the history at any commits you want. There's no real porcelain
for that as no one needed to fine-tune shallow checkouts before, but it's a
straightforward thing to add. Just delete a commit object, making
everything below it unreachable; the reference stays so all hashes remain
the same and you can fill what you missed from another source.
> While this is true, and has been recognized since the early days of the
> 3.0 (git) conversation, the problem with this format is that it's not in
> any way a "natural" Git repository.
Yes, shallow checkouts see hardly any use. Disk space in general is cheap.
In-breadth repositories are a pretty special use case.
> It's unlikely that anyone would use that format to do serious work with
> Git.
You lose the history, but can add new commits, push, pull, etc as normal.
> It's therefore an export format, and it's not completely clear exactly how
> you would generate that export format from an arbitrary maintainer Git
> repository other than doing pretty much exactly what the 3.0 (quilt)
> format is already doing.
Even just that would be an improvement, for reasons Ian mentioned.
However, this works with merged rather than rebased histories as well: you
can cut the graph at arbitrary points. One natural cut would be: axe
any ancestors of the current upstream release and the previous Debian
package.
> Or whether that format would be useful as an import format, since it's not
> entirely obvious that's a useful starting point for bootstrapping to a
> real Git repository one would use for serious packaging work.
Why? You get a working repository that's hash-compatible with upstream.
It has anything you need for forward work.
(Hash-compatible only if the top commit has no non-dfsg content, that is.)
> It therefore has some minor possible benefits in terms of representation
> (and some drawbacks -- the patches are harder to extract for anyone who
> isn't already using Git), but it doesn't seem to change any of the
> fundamentals of the current situation.
A good majority of free software projects use git, so requiring knowledge
of git is not a big downside. Not so with something as obscure as quilt...
--
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
Reply to: