A simple helper which would

* do nothing (except maybe print a warning) if source format 1.0
* otherwise,
  - ensure relevant options present in d/source/options
  - update d/source/patch-header to match latest version in the manpage
  - nuke any existing d/patches so that the next dgit quilt-fixup will
    normalise d/patches (this might be unnecessary: perhaps
    single-debian-patch will already ensure normalisation)

I think this should be a dgit subcommand because the -maint-merge
workflow shouldn't be used without dgit (since there should be a
canonical, non-rewinding git history that is updated with every upload).

Sean Whitton writes ("Bug#852226: dgit: Want `dgit setup-maint-merge`"):

This is a fine idea, but FYI I don't intend to work on it.

I agree that it should be in the dgit package, but my initial feeling
is that it shouldn't be a dgit subcommand.  I don't want dgit proper
to contain nontrivial amounts of logic for specific workflows.

Is it too confusing if
  dgit foo-bar
and
  dgit-foo-bar
are separate namespaces ?

Or maybe it could be called git-setup-dgit-maint-merge.

Ian.

Dear Ian,

I was thinking of working on it myself, so that's fine!

Regarding keeping in sync with dgit-maint-merge(7), I was thinking of
having this be manual.  I.e. there are two copies of the text in the
dgit source tree, with prominent comments reminding anyone who changes
one of them to change the other.

This is because we otherwise have to introduce logic to substitute
things into the manpage, which doesn't seem worth it for this one case.

I would be happy to write that logic if you would prefer it to be that
way, though -- please let me know.

Yes.  That's just going to cause frustration.

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?

Sean Whitton writes ("Re: Bug#852226: dgit: Want `dgit setup-maint-merge`"):

There is already a Makefile target to generate the manpage from the
pod source.  So yes I would prefer to do this automatically.

Let me think about this.

Ian.

Ian Jackson writes ("Re: Bug#852226: dgit: Want `dgit setup-maint-merge`"):
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.

control: owner -1 !
control: retitle -1 dgit: Want script to setup/update dgit-maint-merge(7) source package configuration

Dear Ian,

I share these goals, and after reading your message, completely agree
with you that this should definitely not be a dgit subcommand.

I think that still makes sense because dgit-maint-merge(7) itself is in
the dgit package.

I don't think that it should be a subcommand of git.  The only git thing
that it will do is `git commit`.  Otherwise, it will do dpkg-source things.

My prototype is ~/bin/maintmerge.  So perhaps just /usr/bin/maintmerge,
or if you are worried about namespacing, debmaintmerge.

But let's leave this for now until I have a better version of the script
(probably Perl since I'm actively trying to learn Perl).

Hello,

I wonder, though: could --quilt=single automatically add auto-commit ?