Re: a poll for Dgit workflows
Ian Jackson writes ("Re: a poll for Dgit workflows"):
> Marco d'Itri writes ("Re: a poll for Dgit workflows"):
> > I cannot comment on other the workflows of specific tools, mostly
> > because I have never managed to find one that would solve some problems
> > that I have, but my own packages do not require anything like that, not
> > even quilt. E.g.:
>
> Thanks for sharing.
>
> But this doesn't really do what I am trying to achieve:
>
> But I think that someone who knows how to use git should be able to
> get the source code for a package in Debian, as a git branch, and
> modify that source code, and share it, and so on, without needing to
> deal with quilt, or learn any of dpkg-source --commit, git-dpm, gbp,
> git-debcherry, debian-git-patch-spoogler, Uncle Tom Cobbly and all.
>
> Implicitly I meant that they also shouldn't need to know who the
> maintainer is, or look it up (unless they want to talk to the
> maintainer, of course).
Stepping back a bit:
The way things are done seems very obvious to the maintainer, and the
maintainer suffers much less from the difficulties. The maintainer
knows where their git repository is and how to work with it. The
maintainer already has copies of the relevant .orig files. The
maintainer is (obviously) familiar with the properties of the source
format they've chosen.
But for a non-maintainer, who picks up some package to double check
something and maybe make a small change, all this is quite painful.
In practice people who need to do that kind of thing don't use git.
They use apt-get source. (Now they can use dgit.)
It's worse if you're a user who isn't very familiar with Debian's
currently-conventional approaches to source code management. To an
outsider those approaches are at best outre' - and of course there are
a gazillion different variations.
What dgit provides right now is a way for anyone to get a git branch
which actually represents the source code which is actually in Debian,
in a format that is directly editable and buildable and which supports
git-native workflows. If the user doesn't want to upload to Debian,
they don't ever need to run dpkg-source; they can ignore quilt (if the
package is in quilt).
dgit also provides a way for any user to do an NMU using a git-based
workflow, without knowing anything about the maintainer's source code
management preferences.
Because few maintainers are using dgit, dgit's users see a synthetic
history. So `git blame' and `git log' are not very useful. This is
the next thing that I need to fix.
What I want to do is get to a point where a maintainer can _keep their
existing workflow_, but _also use dgit to publish their history_.
Ian.
Reply to: