Re: Proposal for a MacPorts'ish commit message template
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
> On Nov 4, 2016, at 1:43 PM, Marko Käningwrote: > >> 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
Hi Larry, On 04 Nov 2016, at 18:34 , Lawrence Velázquezwrote: > 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
On 02 Nov 2016, at 23:33 , Ryan Schmidtwrote: > ...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
On 02 Nov 2016, at 01:03 , Lawrence Velázquezwrote: > 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
> On Nov 4, 2016, at 1:30 PM, Marko Käningwrote: > > 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
Hi, On 02 Nov 2016, at 00:08 , Clemens Langwrote: > 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
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
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
> On Nov 2, 2016, at 5:43 PM, Clemens Langwrote: > > 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
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
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
> On Nov 1, 2016, at 6:51 PM, Marko Käningwrote: > > 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
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
On 01 Nov 2016, at 23:56 , Sterling Smithwrote: > 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
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 Smithwrote: > 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
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äningwrote: > 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