Ian Jackson writes ("Re: Bug#852226: dgit: Want `dgit setup-maint-merge`"):
> Sean Whitton writes ("Re: Bug#852226: dgit: Want `dgit setup-maint-merge`"):
> > We already have several `dgit setup-foo` commands that mess around with
> > the working tree, so it seemed appropriate to me to add this one as
> > another setup- command.
> >
> > How would you feel about shipping it as a standalone script, but then
> > having `dgit setup-maint-merge` call out to that script?
>
> Let me think about this.
I'm afraid that having slept on this I'm more resistant to the idea
that this command should be `dgit anything', and particularly `dgit
setup-anything'. In fact, I'm now more opposed to calling it
`dgit-something', even.
I'm not comfortable with workflow-specific (and, unless unavoidable,
Debian-specific) helpers or functions in dgit proper. This seems to
me to breach an abstraction layer I conceive of, above dgit.
I don't think of dgit as a kind of extensible collection of utilities
with a common data format (contrast git, which is). The set of
principal dgit operations is closed. (Things like `dgit build-source'
are UI improvements which simply provide different combinations of the
existing operations.)
In practical terms, the dgit manpage is a reference manual for the
dgit tool itself. I don't want to add material to it relating to
specific workflows and particularly to fairly ad-hoc programs like
your proposed script. That material would be distracting.
A similar consideration applies to the command namespace.
Also, using `dgit-*' as the name increases the risk that people will
think that this is _the_ way to use dgit. This is a perennial
confusion. Most people who have not had dgit explained to them assume
that it is a competitor to gbp or git-dpm or quilt. (#852090 is a
typical example of this effect.)
This proposed subcommand precisely _is_ part of such a competitor. I
want dgit to remain completely workflow-ignorant, and as far as
possible git-management-tool-ignorant.
So I think that all workflow-specific helpers and utilities should
have names which are not `dgit-foo'. (And if a particular workflow
needs a specific enhancement to dgit, that should be done by a formal
and generic API/interface/protocol/whatever.)
This applies a fortiori to `dgit setup-*'. All the existing `dgit
setup-*' commands are pieces of `dgit setup-new-tree'. They are
provided because dgit clone does certain things; that plus the
principle of composability means that those functions must be
available separately from dgit clone, and that's what `dgit setup-*'
are. (And of course it follows from dgit's design goals that other
kinds of `prepare my package branch' commands should not be required;
`dgit quilt-fixup' is itself very regrettable, but unavoidable -
arising as it does from design mistakes in dpkg-source.)
There are other reasons to want to separate this script from dgit
itself. The script does not need the same level of mature
documentation, QA, command line parsing, configurability, etc., that
dgit has. It is run manually, and its results will normally be
subject to human review. It may want to be written in a different
language (python and bash both seem good options, and are already in
dgit's dependency set).
The name of this new script does not matter very much to its users.
It is run rarely, and its users will mostly have just read the
documentation.
FAOD I am still content for the script to be in the dgit package.
How about:
git deb-maint-merge-prepare
?
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
