Re: Proposal for a MacPorts'ish commit message template

[Rainer Müller]

On 2016-11-04 18:46, Lawrence Velázquez wrote:
> Actually, I might have been thinking about another editor. My vim
> highlights the subject in *green* up until 50 chars, and then black for
> the overflow. But one can probably change that black to red if they want
> :P

.vimrc:
hi def link gitcommitOverflow Error

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Lawrence Velázquez]

> On Nov 4, 2016, at 1:43 PM, Marko Käning  wrote:
> 
>> On 04 Nov 2016, at 18:34 , Lawrence Velázquez  wrote:
>> 
>> It doesn't really do anything differently w.r.t. wrapping, but it
>> highlights subject-line overflow in an alarming red color.
> 
> that’s a nice feature.

Actually, I might have been thinking about another editor. My vim
highlights the subject in *green* up until 50 chars, and then black for
the overflow. But one can probably change that black to red if they want
:P

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

Hi Larry,

On 04 Nov 2016, at 18:34 , Lawrence Velázquez  wrote:

> It doesn't really do anything differently w.r.t. wrapping, but it
> highlights subject-line overflow in an alarming red color.

that’s a nice feature. Will have to test whether that works as documented
in our WorkingWithGit wiki page...


> Not a waste of time! Can't know what the water is like without dipping
> your toe in. We appreciate your enthusiasm :)

Well, I respect the work you guys have been done and are doing for MacPorts
and I appreciate that you do the same for those who try to support this
operation to the best of their knowledge.

:)

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

On 02 Nov 2016, at 23:33 , Ryan Schmidt  wrote:

> ...my initial reaction to your template (and my initial reaction when I saw 
> it mentioned previously) was "TL;DR”.

I got it now. :)


>> vim does that with syntax highlighting automatically nowadays when it
>> notices you are writing a commit message. If you need an indication on
>> your line width, may I suggest you configure your editor appropriately?
> 
> Can we document in the WorkingWithGit page how to do that? I have no idea.

I thought exactly the same, Ryan! ;-)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

On 02 Nov 2016, at 01:03 , Lawrence Velázquez  wrote:
> To be honest, this template adds so much comment noise that I can't
> imagine ever using it.

That’s fine ok, your decision. :)


>> --- ~/.git-commit-template ---
>> #  Please enter the commit message for your changes. Lines starting
>> #  with '#' will be ignored, and an empty message aborts the commit.
>> #
>> #   -> The title MUST not be longer than 50 characters. 
> 
> I don't think we should dictate a hard limit on this. Sometimes it's
> hard to say anything meaningful in 50 characters, especially since we
> prepend port names to the subject line. Anything less than 60 chars is
> generally good enough.

Please, check out our own WorkingWithGit wiki page. That’s exactly the
source of information I used to set up the commit template suggestion.
I just included our publicly available commit rules for the committers. 


>> #   -> You MUST wrap all further lines at 72 characters.
>> #
>> #  For more information on how to write commit messages see MacPorts'
>> #  wiki at https://trac.macports.org/wiki/WorkingWithGit#commitmessages
>> #
>> # ==[ Subject: One meaningful line ONLY!  ]==|
>> 
>> # ==[ Blank: Follow the Subject with a blank line, do NOT remove ]=|
>> 
>> # ==[ Details: Describe what changed and explain why it changed]===|
> 
> This is all informative exactly once.

Yes.


> As Clemens already noted, these aren't the supported keywords.

I am aware of that!


>> I have fantasised a little here what concerns the (perhaps upcoming)
>> BUILDBOT feature.
> 
> I wouldn't hold my breath on this.

I am not. I know that this won’t have priority and will only be implemented
if someone really sees a benefit in test-building stuff on an individual
builder.


> We have the wiki and guide for documentation. This template is not the
> place for documentation.

Well, actually, I do see your point. But what good is it if even you didn’t
know the rules about the maximum number of chars in a line? ;-) Having said
that I also think that you’ll mostly have a hard time to bring a conscience
message including the port name into just 50 characters!


>> But perhaps all this is overkill?!
> 
> In case it's not obvious, I think this is serious overkill.

You made very obvious to me.

I do know now what not to do in the future: trying to come up with such kind
of suggestions - while not being a professional software developer and just
some guy who tries to support a collaborative initiative like MacPorts to the
best of his (admittedly) limited knowledge.

Moving on to the next response...
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Lawrence Velázquez]

> On Nov 4, 2016, at 1:30 PM, Marko Käning  wrote:
> 
> Oh, I’d be using vim as well, good to know that it does support git.
> I didn’t know that vim would be able to treat commit message line
> formatting for the first and the 3r+ lines differently with 50 and 72
> chars respectively.

It doesn't really do anything differently w.r.t. wrapping, but it
highlights subject-line overflow in an alarming red color.

> Well, this was a trigger for a discussion about the topic of
> a template which potentially could make the committer’s life easier...
> But I understood in the meantime that I could have just used my spare
> time much better for other things than trying to care about such silly
> things like a commit template. I thought what KDE has is a good
> starting point and I believed MacPorts devs would see value in it.
> I have now been taught that I wasted my time and yours.

Not a waste of time! Can't know what the water is like without dipping
your toe in. We appreciate your enthusiasm :)

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

Hi,

On 02 Nov 2016, at 00:08 , Clemens Lang  wrote:
> Developers are free to use your template if they want to. We don't want
> to mandate using it though (since we couldn't enforce it anyway).

yeah, I am aware of that.


> vim does that with syntax highlighting automatically nowadays when it
> notices you are writing a commit message. If you need an indication on
> your line width, may I suggest you configure your editor appropriately?

Oh, I’d be using vim as well, good to know that it does support git.
I didn’t know that vim would be able to treat commit message line formatting
for the first and the 3r+ lines differently with 50 and 72 chars respectively.


>> # --[ Links to issues on MacPorts' trac ]--|
>> #ISSUE:  
>> #RESOLVES:   
>> #BLOCKED BY: 
> 
> You could have taken the time to actually adjust this to what MacPorts'
> Trac instance accepts. See
> https://trac.edgewall.org/wiki/CommitTicketUpdater
> for the description of the plugins that does this for us and
> https://github.com/macports/trac.macports.org/blob/master/conf/trac.ini#L251
> for the configuration we use.

Yes, I could have, indeed, but I thought it was clear from my post that I was
trying to start a discussion about it and that I didn’t intend to deliver a
ready-made template with everything already prepared. Especially not because
I knew you weren’t fond of the whole idea anyways. How right I was I see from
the responses in this thread. ;-)


>> # --[ Links to other pull requests at GitHub ]—|
>> #PR:  
>> #
>> ##EXAMPLE:
>> # PR:  #123
> 
> Could use the documented keywords GitHub accepts to handle pull requests
> (you can close pull requests from commit messages!)

I could have done this too, yes. But I didn’t know about this GitHub
functionality up to now.


> Additionally, I don't like the upper case keywords.

Well, this was a trigger for a discussion about the topic of a template which
potentially could make the committer’s life easier... But I understood in the
meantime that I could have just used my spare time much better for other
things than trying to care about such silly things like a commit template.
I thought what KDE has is a good starting point and I believed MacPorts devs
would see value in it. I have now been taught that I wasted my time and yours.
Fine with me.

Moving on to the next response...
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Rainer Müller]

On 2016-11-02 23:46, Ryan Schmidt wrote:
>> Which editor are you using? It differs by editor.
> 
> Well, you mentioned vim. Very occasionally I use that. I don't
> remember seeing any particular syntax highlighting in it when editing
> a commit message.

You would need these settings in your ~/.vimrc, which enable syntax
highlighting in general:

  filetype plugin indent on
  syntax on

On the first line, the text color will change after 50 characters.
The second line will turn red if it is not blank as supposed to be.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Clemens Lang]

On Wed, Nov 02, 2016 at 05:46:16PM -0500, Ryan Schmidt wrote:
> Well, you mentioned vim. Very occasionally I use that. I don't
> remember seeing any particular syntax highlighting in it when editing
> a commit message.

You need syntax highlighting (:syntax on) and ideally color enabled.
Additionally, the filetype must be set to 'gitcommit' (:setfiletype
gitcommit). I have "syntax on" in my ~/.vimrc and the filetype is
automatically set when I get prompted for a git commit message. I don't
know how that happens.

To enforce a certain textwidth, you can just :set textwidth=72. Text
typed after you set this will automatically wrap. Other text can be
reflowed, for example by selecting it in visual mode (shift+v) and
pressing gq.

> Usually I use TextWrangler or TextMate.

TextMate has a file type for git commit messages. Unfortunately, it only
seems to highlight overlong summary lines and nothing else (e.g. it does
not warn you about text in the second line). You can get a wrap column
in TextMate using View > Show Wrap Column and set the position of the
line in View > Wrap Column...

I do not know TextWrangler.

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Ryan Schmidt]

> On Nov 2, 2016, at 5:43 PM, Clemens Lang  wrote:
> 
> On Wed, Nov 02, 2016 at 05:33:28PM -0500, Ryan Schmidt wrote:
>>> vim does that with syntax highlighting automatically nowadays when
>>> it notices you are writing a commit message. If you need an
>>> indication on your line width, may I suggest you configure your
>>> editor appropriately?
>> 
>> Can we document in the WorkingWithGit page how to do that? I have no
>> idea.
> 
> Which editor are you using? It differs by editor.

Well, you mentioned vim. Very occasionally I use that. I don't remember seeing 
any particular syntax highlighting in it when editing a commit message.

Usually I use TextWrangler or TextMate.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Clemens Lang]

On Wed, Nov 02, 2016 at 05:33:28PM -0500, Ryan Schmidt wrote:
> > vim does that with syntax highlighting automatically nowadays when
> > it notices you are writing a commit message. If you need an
> > indication on your line width, may I suggest you configure your
> > editor appropriately?
> 
> Can we document in the WorkingWithGit page how to do that? I have no
> idea.

Which editor are you using? It differs by editor.

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Ryan Schmidt]

MacPorts used CVS commit templates 10 years ago. This was before my involvement 
with MacPorts, so I don't know how it was decided to do that in the first place 
or what developer opinions about it were. But you don't have to look at too 
much of the history of the repositories from 2006 and prior to see what a 
disaster it was. Developers would fill in some fields and not others, or 
completely ignore the template and write their own message above or below it. 
Maybe with instructional comments it would be better, on the other hand, my 
initial reaction to your template (and my initial reaction when I saw it 
mentioned previously) was "TL;DR".


On Nov 1, 2016, at 6:08 PM, Clemens Lang wrote:
> 
> On Tue, Nov 01, 2016 at 11:51:52PM +0100, Marko Käning wrote:
> 
>> as I find it on the console quite handy to know when 50 or 72
>> characters are reached in a line:
> 
> vim does that with syntax highlighting automatically nowadays when it
> notices you are writing a commit message. If you need an indication on
> your line width, may I suggest you configure your editor appropriately?

Can we document in the WorkingWithGit page how to do that? I have no idea.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Lawrence Velázquez]

> On Nov 1, 2016, at 6:51 PM, Marko Käning  wrote:
> 
> I know that many of you weren't in favour of a commit message template,
> but I propose one anyway, which I derived from KDE’s neat one, as I find
> it on the console quite handy to know when 50 or 72 characters are
> reached in a line:

To be honest, this template adds so much comment noise that I can't
imagine ever using it.

> --- ~/.git-commit-template ---
> #  Please enter the commit message for your changes. Lines starting
> #  with '#' will be ignored, and an empty message aborts the commit.
> #
> #   -> The title MUST not be longer than 50 characters. 

I don't think we should dictate a hard limit on this. Sometimes it's
hard to say anything meaningful in 50 characters, especially since we
prepend port names to the subject line. Anything less than 60 chars is
generally good enough.

> #   -> You MUST wrap all further lines at 72 characters.
> #
> #  For more information on how to write commit messages see MacPorts'
> #  wiki at https://trac.macports.org/wiki/WorkingWithGit#commitmessages
> #
> # ==[ Subject: One meaningful line ONLY!  ]==|
> 
> # ==[ Blank: Follow the Subject with a blank line, do NOT remove ]=|
> 
> # ==[ Details: Describe what changed and explain why it changed]===|

This is all informative exactly once.

> # ==[ Fields: Uncomment and edit where applicable ]|
> 
> # --[ Links to issues on MacPorts' trac ]--|
> #ISSUE:  
> #RESOLVES:   
> #BLOCKED BY: 
> #
> ##EXAMPLE:
> # ISSUE: https://trac.macports.org/ticket/98765
> #
> ##NOTE: Don't use '#'-notation, since it's a Pull Request ID on GitHub!
> #
> # --[ Links to other pull requests at GitHub ]—|
> #PR:  
> #
> ##EXAMPLE:
> # PR:  #123

As Clemens already noted, these aren't the supported keywords.

> # --[ FUTURE FEATURE TO IGNORE/TRIGGER BUILDS ON SPECIFIC BUILDBOTS ]--|
> #BUILDBOT: < ignore | list_of_buildbots >
> #
> ##EXAMPLE:
> # BUILDBOT: ignore
> # BUILDBOT: ports-10.9_x86_64 ports-10.12_x86_64
> #
> ##NOTE: This isn't yet implemented at MacPorts' GitHub!
> #
> ##NOTE: See relevant issue: https://trac.macports.org/ticket/52769
> ---
> 
> 
> I have fantasised a little here what concerns the (perhaps upcoming)
> BUILDBOT feature.

I wouldn't hold my breath on this.

> The links section is also just serving as an example, but it might be a
> good idea to define some useful keywords there as well.
> 
> I also introduced a pull request section, which might be nice to have
> for proper documentation, who knows.

We have the wiki and guide for documentation. This template is not the
place for documentation.

> But perhaps all this is overkill?!

In case it's not obvious, I think this is serious overkill.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Clemens Lang]

Hi,

On Tue, Nov 01, 2016 at 11:51:52PM +0100, Marko Käning wrote:
> I know that many of you weren't in favour of a commit message
> template, but I propose one anyway, which I derived from KDE’s neat
> one,

Developers are free to use your template if they want to. We don't want
to mandate using it though (since we couldn't enforce it anyway).

> as I find it on the console quite handy to know when 50 or 72
> characters are reached in a line:

vim does that with syntax highlighting automatically nowadays when it
notices you are writing a commit message. If you need an indication on
your line width, may I suggest you configure your editor appropriately?

> # --[ Links to issues on MacPorts' trac ]--|
> #ISSUE:  
> #RESOLVES:   
> #BLOCKED BY: 

You could have taken the time to actually adjust this to what MacPorts'
Trac instance accepts. See
 https://trac.edgewall.org/wiki/CommitTicketUpdater
for the description of the plugins that does this for us and
 https://github.com/macports/trac.macports.org/blob/master/conf/trac.ini#L251
for the configuration we use.

> # --[ Links to other pull requests at GitHub ]—|
> #PR:  
> #
> ##EXAMPLE:
> # PR:  #123

Could use the documented keywords GitHub accepts to handle pull requests
(you can close pull requests from commit messages!)

Additionally, I don't like the upper case keywords.

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

On 01 Nov 2016, at 23:56 , Sterling Smith  wrote:

> Remind me, would using this template still give the commented git status 
> (which is the default)?

Yes, make a change and test it like this:

 $ git commit -a -t ~/.git-commit-template

The status gets appended at the bottom.

Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Sterling Smith]

To answer myself, according to 
https://git-scm.com/book/tr/v2/Customizing-Git-Git-Configuration
the answer is yes, there is still the commented git status.

-Sterling

On Nov 1, 2016, at 3:56PM, Sterling Smith  wrote:

> Remind me, would using this template still give the commented git status 
> (which is the default)?
> 
> -Sterling
> 
> On Nov 1, 2016, at 3:51PM, Marko Käning  wrote:
> 
>> Hi MacPorts’ GitHubians,
>> 
>> I know that many of you weren't in favour of a commit message template,
>> but I propose one anyway, which I derived from KDE’s neat one, as I find
>> it on the console quite handy to know when 50 or 72 characters are
>> reached in a line:
>> 
>> 
>> 
>> --- ~/.git-commit-template ---
>> #  Please enter the commit message for your changes. Lines starting
>> #  with '#' will be ignored, and an empty message aborts the commit.
>> #
>> #   -> The title MUST not be longer than 50 characters. 
>> #
>> #   -> You MUST wrap all further lines at 72 characters.
>> #
>> #  For more information on how to write commit messages see MacPorts'
>> #  wiki at https://trac.macports.org/wiki/WorkingWithGit#commitmessages
>> #
>> # ==[ Subject: One meaningful line ONLY!  ]==|
>> 
>> # ==[ Blank: Follow the Subject with a blank line, do NOT remove ]=|
>> 
>> # ==[ Details: Describe what changed and explain why it changed]===|
>> 
>> # ==[ Fields: Uncomment and edit where applicable ]|
>> 
>> # --[ Links to issues on MacPorts' trac ]--|
>> #ISSUE:  
>> #RESOLVES:   
>> #BLOCKED BY: 
>> #
>> ##EXAMPLE:
>> # ISSUE: https://trac.macports.org/ticket/98765
>> #
>> ##NOTE: Don't use '#'-notation, since it's a Pull Request ID on GitHub!
>> #
>> # --[ Links to other pull requests at GitHub ]—|
>> #PR:  
>> #
>> ##EXAMPLE:
>> # PR:  #123
>> #
>> #
>> # --[ FUTURE FEATURE TO IGNORE/TRIGGER BUILDS ON SPECIFIC BUILDBOTS ]--|
>> #BUILDBOT: < ignore | list_of_buildbots >
>> #
>> ##EXAMPLE:
>> # BUILDBOT: ignore
>> # BUILDBOT: ports-10.9_x86_64 ports-10.12_x86_64
>> #
>> ##NOTE: This isn't yet implemented at MacPorts' GitHub!
>> #
>> ##NOTE: See relevant issue: https://trac.macports.org/ticket/52769
>> ---
>> 
>> 
>> 
>> I have fantasised a little here what concerns the (perhaps upcoming)
>> BUILDBOT feature.
>> 
>> The links section is also just serving as an example, but it might be a
>> good idea to define some useful keywords there as well.
>> 
>> I also introduced a pull request section, which might be nice to have
>> for proper documentation, who knows.
>> 
>> But perhaps all this is overkill?!
>> 
>> Suggestions are welcome.
>> 
>> Marko
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Sterling Smith]

Remind me, would using this template still give the commented git status (which 
is the default)?

-Sterling

On Nov 1, 2016, at 3:51PM, Marko Käning  wrote:

> Hi MacPorts’ GitHubians,
> 
> I know that many of you weren't in favour of a commit message template,
> but I propose one anyway, which I derived from KDE’s neat one, as I find
> it on the console quite handy to know when 50 or 72 characters are
> reached in a line:
> 
> 
> 
> --- ~/.git-commit-template ---
> #  Please enter the commit message for your changes. Lines starting
> #  with '#' will be ignored, and an empty message aborts the commit.
> #
> #   -> The title MUST not be longer than 50 characters. 
> #
> #   -> You MUST wrap all further lines at 72 characters.
> #
> #  For more information on how to write commit messages see MacPorts'
> #  wiki at https://trac.macports.org/wiki/WorkingWithGit#commitmessages
> #
> # ==[ Subject: One meaningful line ONLY!  ]==|
> 
> # ==[ Blank: Follow the Subject with a blank line, do NOT remove ]=|
> 
> # ==[ Details: Describe what changed and explain why it changed]===|
> 
> # ==[ Fields: Uncomment and edit where applicable ]|
> 
> # --[ Links to issues on MacPorts' trac ]--|
> #ISSUE:  
> #RESOLVES:   
> #BLOCKED BY: 
> #
> ##EXAMPLE:
> # ISSUE: https://trac.macports.org/ticket/98765
> #
> ##NOTE: Don't use '#'-notation, since it's a Pull Request ID on GitHub!
> #
> # --[ Links to other pull requests at GitHub ]—|
> #PR:  
> #
> ##EXAMPLE:
> # PR:  #123
> #
> #
> # --[ FUTURE FEATURE TO IGNORE/TRIGGER BUILDS ON SPECIFIC BUILDBOTS ]--|
> #BUILDBOT: < ignore | list_of_buildbots >
> #
> ##EXAMPLE:
> # BUILDBOT: ignore
> # BUILDBOT: ports-10.9_x86_64 ports-10.12_x86_64
> #
> ##NOTE: This isn't yet implemented at MacPorts' GitHub!
> #
> ##NOTE: See relevant issue: https://trac.macports.org/ticket/52769
> ---
> 
> 
> 
> I have fantasised a little here what concerns the (perhaps upcoming)
> BUILDBOT feature.
> 
> The links section is also just serving as an example, but it might be a
> good idea to define some useful keywords there as well.
> 
> I also introduced a pull request section, which might be nice to have
> for proper documentation, who knows.
> 
> But perhaps all this is overkill?!
> 
> Suggestions are welcome.
> 
> Marko
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Proposal for a MacPorts'ish commit message template

[Marko Käning]

Hi MacPorts’ GitHubians,

I know that many of you weren't in favour of a commit message template,
but I propose one anyway, which I derived from KDE’s neat one, as I find
it on the console quite handy to know when 50 or 72 characters are
reached in a line:



--- ~/.git-commit-template ---
#  Please enter the commit message for your changes. Lines starting
#  with '#' will be ignored, and an empty message aborts the commit.
#
#   -> The title MUST not be longer than 50 characters. 
#
#   -> You MUST wrap all further lines at 72 characters.
#
#  For more information on how to write commit messages see MacPorts'
#  wiki at https://trac.macports.org/wiki/WorkingWithGit#commitmessages
#
# ==[ Subject: One meaningful line ONLY!  ]==|

# ==[ Blank: Follow the Subject with a blank line, do NOT remove ]=|

# ==[ Details: Describe what changed and explain why it changed]===|

# ==[ Fields: Uncomment and edit where applicable ]|

# --[ Links to issues on MacPorts' trac ]--|
#ISSUE:  
#RESOLVES:   
#BLOCKED BY: 
#
##EXAMPLE:
# ISSUE: https://trac.macports.org/ticket/98765
#
##NOTE: Don't use '#'-notation, since it's a Pull Request ID on GitHub!
#
# --[ Links to other pull requests at GitHub ]—|
#PR:  
#
##EXAMPLE:
# PR:  #123
#
#
# --[ FUTURE FEATURE TO IGNORE/TRIGGER BUILDS ON SPECIFIC BUILDBOTS ]--|
#BUILDBOT: < ignore | list_of_buildbots >
#
##EXAMPLE:
# BUILDBOT: ignore
# BUILDBOT: ports-10.9_x86_64 ports-10.12_x86_64
#
##NOTE: This isn't yet implemented at MacPorts' GitHub!
#
##NOTE: See relevant issue: https://trac.macports.org/ticket/52769
---



I have fantasised a little here what concerns the (perhaps upcoming)
BUILDBOT feature.

The links section is also just serving as an example, but it might be a
good idea to define some useful keywords there as well.

I also introduced a pull request section, which might be nice to have
for proper documentation, who knows.

But perhaps all this is overkill?!

Suggestions are welcome.

Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev