Allow '#' at the start of commit message

[Zipher04]

Allow commit message to start a new line with # and not followed by a space. In order to match #ID in the message.

For example, the following issue ID 58 can be matched now.

# HG changeset patch
# User Zipher <zipher@aa.com>
# Date 1500962954 -28800
# Node ID ef1876ac05842f491ebb9cff6dfc5d5ea6d4fff9
# Parent  8244ce736dde867b849edf8618d0b116312d4575
Add circuit diagram.
#58

diff -r 8244ce736dde -r ef1876ac0584 Panel.png
Binary file Panel.png has changed

[dregad]

The plugin offers out of the box a mechanism to parse commit messages for issue id references, which can configured with a custom regex (default is /(?:bugs?|issues?|reports?)+\s*:?\s+(?:#(?:\d+)[,\.\s]*)+/i) so I'm fairly confident that what you want to do can be achieved without changing the code as per your suggestion.

I'm going to close this for now, feel free to reopen should you find that the standard feature does not satisfy your requirement or if I misunderstood the problem.

[Zipher04]

The regex in Source Control Integration is used to match issue id in the commit message. But if any line start with a '#' sign, Source HgWeb Integration will treat it as special case and did not add them into commit message.

For example, in the original code, a HG commit message of

Add circuit diagram.
#58

will cause Source HgWeb to get a commit message of only

Add circuit diagram.

The issue id is not treat as commit message and the regex in Source Control Integration cannot find it.

Any line start with a '#' and is not followed by ' User', ' Date', ' Node', or ' Parent' will be ignore by the original code. I modified it to treat lines start with '#' but not followed by space as commit message, too.

[Zipher04]

Sorry, I am not sure how to reopen this PR. I found this guide https://github.com/gitbucket/gitbucket/issues/378 It seem only the 'owner' can reopen this.

[morgant]

@Zipher04 I'm pretty sure most VCS ignore message lines beginning with a hash/pound/'#' symbol, so such a line is unlikely to even reach the SourceIntegration plugin intact. This is certainly the case with Subversion & Git.

[dregad]

@Zipher04 thanks for the clarification.

I found this guide gitbucket/gitbucket#378 It seem only the 'owner' can reopen this.

gitbucket != github.

Anyway, now that I understand what the problem is, I'll reopen the PR.

@morgant I don't use Mercurial myself, but after a a quick test it appears there is no special handling for #; when interactively editing commit message, lines starting with HG: are treated as comments and ignored.

For the record, with Git it is possible to have lines starting with #, if you

• Change the default comment char (not sure if Mercurial can do this)

• specify the commit message on the command line. e.g.

  $ git commit -a -m "test                                                               
  
  #123"
  [master 1bad1c0] test
  
  $ git log -1
  commit 1bad1c05db6b07705043119be7d835617405603c (HEAD -> master)
  Author: root <root@localhost>
  Date:   Wed Aug 23 13:00:58 2017 +0000
  
      test
  
      #123

[morgant]

@dregad Thanks for testing with mercurial, I should have checked before commenting!

That's a good note about changing the comment character, does that mean we should not handle the comment lines at all (shouldn't the VCS have stripped them before they get to a SourceIntegration plugin anyway)?

[dregad]

I should have checked before commenting!

Heh :wink:

we should not handle the comment lines at all

AFAIK we currently don't have any special handling for comments, and I don't believe we should.

In the Mercurial plugin's case, the lines beginning with # are not really comments: they are the header of the raw changeset output (as shown in the PR's description) which the plugin parses to retrieve commit metadata, and are not actually part of the commit message itself.

Looking at Mercurial source, the raw changeset output is actually defined by a template. This means that a customized template might cause the plugin to break, but that's already the case today.

Anyway, I believe we could be more specific in the plugin's code to parse only the headers defined in that template, and leave all the rest out to be treated as commit message text.

[dregad]

Fixed in a0e9d0af84938e316b9ccb1b4e094429b7dc9b5f