On Sun, Jul 19, 2015 at 11:28 PM, Ian Jackson < ijack...@chiark.greenend.org.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I am pleased to announce dgit 1.0, which can be used, as applicable, > by all contributors and downstreams. > > dgit allows you to treat the Debian archive as if it were a git > repository, and get a git view of any package. If you have the > appropriate access rights you can do builds and uploads from git, and > other dgit users will see your git history. > > (dgit's git histories are often disjoint from the maintainer's > history; this is because the dgit git tree has exactly the same > content as the archive, which maintainers' histories often don't.) > Apologies if this has been answered elsewhere before, but I’d like to better understand how dgit fits into the workflow of working on packages which use git-buildpackage. 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? 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? 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? Is dgit intended to be used only if the package does not already use e.g. git-buildpackage? Is dgit intended to be used as a replacement for tools like git-buildpackage? -- Best regards, Michael
