The guidelines in the Pro-Git book match what has been said here and have some
more detail and explanation (the book says 50 for the first line, but 80 seems
reasonable).
http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines
Snippet copied here (much more in the link):
"... As a general rule, your messages should start with a single line that’s no
more than about 50 characters and that describes the changeset concisely,
followed by a blank line, followed by a more detailed explanation. The Git
project requires that the more detailed explanation include your motivation for
the change and contrast its implementation with previous behavior — this is a
good guideline to follow. It’s also a good idea to use the imperative present
tense in these messages. In other words, use commands. Instead of "I added
tests for" or "Adding tests for," use "Add tests for." …"
Regarding long lines, it is up to the message author to line wrap. Github does
recognize when a branch has been merged locally and updates the corresponding
pull request accordingly, so it is possible for developers to manage the merge
commit messages. The downside to merging locally is we lose the ability to
revert and restore the work using the github UI, which is much more pleasant to
use than the equivalent command line processes (even for intermediate/advanced
git users - maybe not expert git users). The upside, of course, is the person
conducting the merge can control the merge commit message.
Other projects that use a more involved code review tool, like gerrit,
configure the tool to handle the merge and have much greater control over what
the merge commit message is. However, using those tools usually adds more
complexity and overhead to the review process. As the project grows there might
be benefits, but for now it seems simple enough to manage the merge commits on
our own.
I updated the GitCheatsheet.txt with the log commands.
Thanks!
Thomas Van Doren
On 8/7/14, 1:06 PM, "Brad Chamberlain" <[email protected]<mailto:[email protected]>>
wrote:
As somebody who reviews those first lines with some regularity (status
reports, meetings, releases, etc.) if you could figure out an explanation
that fit within 75-80 characters (as we asked in the SVN days), that would
make my life a whole lot easier. It need not say everything, just provide
a headline.
-Brad
On Thu, 7 Aug 2014, Vassily Litvinov wrote:
Here are my considerations:
* I often make the first line of my merge message quite long - this allows me
to summarize my changes more comfortably.
* Within the message, it makes sense to me to have (a) one line per paragraph
and/or (b) restrict each line so it fits on one line when I view it using
'git log' in my emacs (which implies <=75 chars).
Although I can probably live with other arrangements as well.
Vass
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/chapel-developers
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
