Re: dgit 1.0, available for all users
Michael Stapelberg writes ("Re: dgit 1.0, available for all users"):
> Let’s assume I want to make an improvement to a package. I’d start by
> cloning it using dgit, then I’d make my modifications, but then what?
> Typically I’d use git format-patch and send the resulting file to the
> maintainer to get my changes reviewed, so I cannot use dgit push, because
> that would directly upload to the Debian archive, right?
Indeed. But if you don't get a reply from the maintainer, or the
maintainer says "yes please", or you're RC bug squashing during the
freeze, or the maintainer has already said "yes please NMU"
(generally, or for the specific problem) before you even made the
patch, you can then dgit push.
> Even in the case where I am the maintainer and don’t deem it necessary to
> have my changes reviewed, I’d want to push my changes to the
> git-buildpackage repository, not directly to the archive, so that a more
> fine-grained history is preserved for future package archeology. Again, I
> cannot use dgit push, right?
If you `dgit push' your changes to the archive, your fine grained
history is stored on the dgit git server and can be browsed, viewed,
and cloned, by anyone. See, for example:
https://browse.dgit.debian.org/dgit.git/log/
(Hmm, I see I failed to squash a fixup! commit in that history. Oh
well - too late now.)
> In case I’m correct about both of these points, what’s the advantage of
> using dgit over e.g. “apt-get source && git init && git add . && git commit
> -a -m "Initial import"”? Having the package history as seen by the Debian
> archive in git?
What you are describing is debcheckout.
dgit's advantage over debcheckout from the pov of an NMUer is that it
can be used to do the upload. It will make sure that what you are
uploading is exactly the git tree that you intend. And in the case of
a `3.0 (quilt)' package it will handle the quiltification for you. So
the workflow for an NMUer looks entirely git-based.
dgit's advantage for a maintainer is that it publishes your history in
a way where everyone can find and use it, without knowing about your
package's special arrangements.
This is useful to you because it means that another dgit user (for
example, an NMUer or a patch submitter - see above) who sends you git
branches (either out of band, or via dgit push) will send you git
branches based on your git history, not on some debcheckout. Or, more
likely, it means that they will send you a git branch at all - at the
moment an NMUer knows that even if they find your git repo it might
well have some special-snowflake structure, so they probably won't
bother looking for it, and will just make a patch.
And of course there is a benefit for everyone else, if you as
maintainer use dgit push to do your uploads: everyone else who uses
dgit clone will see your git history, which is likely to be much more
useful to them that the debcheckout-like stub dgit has to synthesise
otherwise.
> Is dgit intended to be used only if the package does not already use e.g.
> git-buildpackage?
No.
> Is dgit intended to be used as a replacement for tools like
> git-buildpackage?
No.
Use of dgit is mostly-orthogonal to the maintainer's git patch
management approach (if any). dgit is intended to complement existing
git packaging tools.
Ian.
Reply to: