Partha Aji wrote: > Just an observation here.. I generally prefer using git ci-m "message" > vs using an editor.. But if we have git commit format regulations I > guess I'll have to use vi.. Would be nice though if I could stick to -m... >
I really like using '-m' as well, but you can do multi-line comments with it as well: # git commit -a -m 'this is a short commit message > > and this is the longer more detailed explanation that may goon and on and can > > even span paragraphs' Newlines work just fine between quotes. > > Jesus M. Rodriguez wrote: >> Devan Goodwin wrote:i >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On Mon, 30 Mar 2009 22:37:12 -0400 >>> Jesus Rodriguez <jes...@redhat.com> wrote: >>> >>>> Today we have two commit formats. If you are fixing a bug the format >>>> is: >>>> bznumber - msg >>>> >>>> If it is not a bug fix, it is just: >>>> >>>> msg >>>> >>>> This has been working out ok so far. But we're getting more >>>> descriptive in our commits which is good for looking back at history >>>> but sucks for changelogs and 'git log --pretty=oneline' >>>> >>>> James Bowes' made reference to a summary line followed by a blank line >>>> then a detailed paragraph. I didn't think much of it, until I saw >>>> vim change colors as I was typing. >>>> >>>> http://zeusville.files.wordpress.com/2009/03/git-commit.png >>>> >>>> Here's a summary: >>>> >>>> First line would be 50 character summary (including 6 digit bug number >>>> if needed). Followed by a blank line, then several paragraphs >>>> wrapped at 72 characters. >>>> >>>> What do you think? I know 50 characters isn't much so it will force >>>> us to be very wise with our words in the first line. But it will >>>> certainly make changelogs and 'git log --pretty=oneline' much >>>> easier to work with. >>>> >>>> Here's another post on the subject from the Rails folks: >>>> http://www.tpope.net/node/106 >>>> >>>> Thoughts? I suspect the lengths will cause folks to balk at this >>>> suggestion :) >>>> >>> >>> +1 here. I try to do this in general although with longer line >>> lengths, I try to stick to 80 chars for first line and whatever vim >>> does for the rest. >>> If the line lengths don't fly could we agree on just a single line >>> summary (preferably < 72 chars), blank line, then all the details you >>> want. (and we don't care about the line length there) >> >> The 50 characters was a suggestion :) I could live with a oneline >> summary then longer messages separated by a blank line. >> >> My biggest fear with the 50 character limit was 'fixed bug' type >> of commit messages. >> >> jesus >> > > _______________________________________________ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel -- Justin Sherrill, RHCA 1801 Varisty Drive. Software Engineer Raleigh, NC 27603 Red Hat, Inc. _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
