Jesus Rodriguez 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 :)
To me this whole thread is currently personal preferences on how people
work. I think Jesus's suggestion should be used as a guidance, rather
than a hard and fast rule. To me, if a one line summary is enough
information to describe the change, and the commit itself is self
contained enough to be easy to understand, then great. If though the
commit is large, goes over multiple files, not easy to grock, then the
usage of summary, blank line, details as Jesus suggested does allow for
more freedom to help explain the commit for others who may review/read
it. Does this sound sane? :)
Also - restricting summary to certain char - I do not think will work,
there will always be someone who finds it too short!
Cliff
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
