commit IDs in changelog messsages (was: Introductory mail)

martin f krafft madduck at
Thu Nov 13 10:22:56 UTC 2008

also sprach Stefano Zacchiroli <zack at> [2008.11.13.1109 +0100]:
> OK, but note that there are drawbacks. For example if we go for
> "(Git:af14e5)" that would be annoying, as parsing will depend on the
> number of supported, or "known", VCS. That was a wrong design choice
> of Vcs-* which I don't want to repeat.

I am not sure I agree. Maybe in the context of debian/control, but
I don't see the shortcomings for what we're trying to do.

Let's assume we copy the same scheme as Closes, meaning that
/[cC]loses:\s*(#?\d{6,}(,\s*#?\d{6,})*)/ yields the list of bugs in
$1, then we ought to have something similar for VCS commits.

But instead of one parser, I'd really rather think of it as a number
of parsers, each getting a chance. So Closes would be handled by the
dak-bts parser, and Git: by a git parser, SVN: by an SVN parser,

So, in any context, there will be a set of parsers, and when we
encounter Bazaar: but there is no Bazaar parser (assuming that...),
then a "Commit:Bazaar:" would not provide use with any more
information, really: we still couldn't parse it, even though
a generic Commit: parser might get a chance to. Yet, as you said,
the generic Commit: parser would not have knowledge about each VCS
(which I think is the design error you mention), so the benefit
would stay 0.

 .''`.   martin f. krafft <madduck at>
: :'  :  proud Debian developer, author, administrator, and user
`. `'` -
  `-  Debian - when you have better things to do than fixing systems
"most people become bankrupt through having invested too heavily in
 the prose of life. to have ruined one's self over poetry is an
                                                        -- oscar wilde
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature (see
Url : 

More information about the vcs-pkg-discuss mailing list