Re: Introducing dgit - git integration with the Debian archive
Raphael Hertzog writes ("Re: Introducing dgit - git integration with the Debian archive"):
> This is wrong on so many levels...
I don't think we are going to agree. I stand by the description in
the dgit manpage.
> > 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
I have found that by setting EDITOR this can be made to work. I wrote
a shonky thing to edit the patch description into something halfway
reasonable. (I was tempted by EDITOR=true but maintainers would hate
the resulting patches.)
Did you know that dpkg-source doesn't notice if sensible-editor exits
nonzero ?
> > 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?
No, not really. I do that already, but there is still a race.
> 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.
If this happens you can just say "dgit pull", or "dgit fetch" followed
by an explicit merge, and the right thing will happen. dgit will
prevent you from accidentally overwriting the 1.0-2 changes - but only
if the 1.0-2 changes either (a) were made with dgit (b) have shown up
in your mirror.
> 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.
Those branches aren't in refs/heads/ precisely to stop git pushing
them by itself.
> 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?
Doing that isn't a good idea, indeed. You can do this with your local
dgit/<suite> branch but the remote suite tracking branches track
uploads only. You can make a refs/heads/<suite> branch if you want to
share your work.
> 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).
Maybe there should be a way to make the dgit-repos tree a symlink to
the collab-maint tree. Of course doing that would make it impossible
ever to sever the two services.
Ian.
Reply to: