Dear Maintainer,

I'm trying to exclude upstream logs from debian/changelog, or more
precisely, just saying that a new upstream release was merged.

Here is my use case:

    o-o-o-o-C <- upstream/1.3.4
       \     \
    o-o-A-B-o-D-E-F <- debian/1.3.4-1

- B: Last debian package (commit registering the git-dch call

- C: commit pointed by the tag upstream/1.3.4

- D: merge commit with message "New upstream release"

- E: commit to update the packaging (whatever happens under "debian/")

- F: commit registering the git-dch call


In my debian/changelog, I want something like:

    package (1.3.4-1) UNRELEASED; urgency=low

      * [2291ce3] New upstream release
      * [8517689] Bump standard version

Hello,

I just began to work on this issue on a temporary branch[1].

I wonder if we could not factorize the string expansion across all tools
and how we could do it.

One option is to factorize the options management in reusable parsers
and let all tools use them with the "parents" option of
"argparse.ArgumentParser", then we could add an "expand" method to the
"options" and use it when needed.

Any idea?

Regards.


Footnotes:
[1]  http://git.baby-gnu.net/gitweb/?p=git-buildpackage.git;a=shortlog;h=refs/heads/feature/git-dch-define-more-replacement-strings

This would need a new section in gbp.conf

[replacements]
last_upstream = ...
foo = cmd1
bar = cmd2

Im undecided if the rhs should be evaluated by a shell or by python but
we probably want both.

If you create a derived class from string and return that from optparse
you can use "{foo} {bar}".format() whenever the actual option gets used
(not when evaluated during Option.parse()). Isn't ttmore what we want?
You'd need to override the format() method of that new string class of
course to fill in all values from replacements by default. Does this
make sense?
Cheers,
 -- Guido

Hmm, I dislike the idea of running arbitrary shell (or Python) code from
the command line. How about just allowing few git commands (through
gbp.git) and python regex or something.

I'm even planning to implement a '--no-hooks' command line option to
prevent running any hooks.

This probably makes more sense.

Thanks,
 Markus

On Tue, Apr 16, 2013 at 10:34:14AM +0300, Markus Lehtonen wrote:
[..snip..]

We could have all of them off by default. I'm not 100% sure we need this
either especially since Daniel's use case doesn't need arbitrary python
code but just some additional command line options but if it's
implemented consistently (and can be turned off easily) I have no
objections in merging it.

That would probably make sense too.
Cheers,
 -- Guido

Guido Günther <agx@sigxcpu.org> writes:

Hello,

I'm not sure about making it configurable, but that's probably because I
can't find use case for it.

The %(since)s and %(last_upstream)s require calculation far too
complicated for a single command and looks relevant only for git-dch.

I don't find a good way to derived a class from string and fill all the
values.

Only replacements defined in the configuration could be filled after
options parsing.

For example, the %(version)s means sometime the debian version, sometime
the upstream one, and is set:

- from command line

- from origin tarball

- from gbp.deb.DscFile

- from DebianGitRepository.debian_version_from_upstream, called by
  gbp.scripts.dch.guess_version_from_upstream

- from debian/changelog

Overriding the “.format()” method does not exclude the need to pass some
replacement values only relevant for some command to some options and
only after some calculation.

Regards.