Re: Introducing dgit - git integration with the Debian archive
On Sat, 24 Aug 2013, Ian Jackson wrote:
> > Well doing the right things with "3.0 (quilt)" means (for most people)
> > to keep the source package tree actually usable with quilt, so actually
> > recording "non-quilt managed" changes in a new quilt patch.
>
> IMO the design should have been that the quilt user would do this
> after having unpacked the package.
This is wrong on so many levels...
Where would we record the changes made outside of the debian directory?
If you don't want to feed them back in the debian directory as new quilt
patch, then you're forced to treat them like we do with binary files aka
add them in the .debian.tar.gz even though they're outside of the debian
directory. The goal of "3.0 (quilt)" was to always the represent the
source package as a debian directory + a stack of patches to apply on the
.orig.tar. Refusing to create a new quilt patch for unmanaged changes
would break this principle.
It's not only about convenience for Debian, it's also about doing the
right thing wrt upstream (and anybody who peeks at our source packages) by
always having all our changes as a set of patches that do apply on the
latest upstream releases.
> > But you should be aware that it's an interactive command, it will ask for
> > the patch name (thought this can be avoided by feeding it on the command
> > line) and it will run sensible-editor to let the user edit the DEP-3
> > metadata on top of the generated patch.
>
> I will RTFM to use it in some noninteractive way by generating the
> arguments automatically.
You can't do that with dpkg-source --commit. But if you don't want the
interactive process, just use --auto-commit when you build the source
package.
That said we could enhance "dpkg-source --commit" to not run the editor when
stdin is not a tty.
> > And the content is taken from the parent which represents the uploads? So
> > basically you overwrite any other changes that might have been done since
> > the last upload? Otherwise there's no point in that pseudo-merge if it
> > doesn't grab the changes made by this upload.
>
> I think you're confused. We are talking here about the import from
> the archive, not the upload to it.
That's what I meant, anything that is in the archive has been uploaded
before so it's also an upload, just not the same ;-)
> But it is true that if you make an upload you overwrite the changes
> made in any recent uploads you haven't explicitly merged into what
> you're uploading. I think this is a fundamental misfeature of the
> archive.
You could avoid this enforcing a dgit pull before dgit push?
I was more thinking of this scenario:
1/ I clone the repository at a time where the archive has 1.0-1
2/ I add some commit/changes
3/ Someone else uploads 1.0-2
4/ I import the 1.0-2 source archive (with dgit pull)
But I guess that in fact this scenario is fine since the branch where that
pseudo-merge happens is the (remoted) dgit one, not the one where I'm working.
And I guess that you're not allowed to push anything in the dgit/*
branches (on dgit.debian.net) except when you do a real upload. Thus if
multiple people have to collaborate to prepare the next revision, they
must do so on another branch. The dgit branch cannot be used to accumulate
changes in preparation of the next upload.
Is that correct?
> The central repositories are fundamental to the design.
I understand that, it's still a pity that a maintainer can't indicate that
his usual repository should be used as the central dgit repository for
this package.
In particular when moving to dgit-repos (which is the only solution if he
wants to avoid the duplication) implies loosing the possibility to
hand out access to non-DD (which collab-maint makes possible).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
Reply to: