On Tue, Mar 31, 2009 at 05:46:57PM +0200, Jan Pazdziora wrote: > On Tue, Mar 31, 2009 at 11:17:18AM -0400, James Bowes wrote: > > > > Why not? > > Convenience and personal preference. > > It would not allow me to do git commit -m '...' as it's hard to count > the letters on the command line. I know that if I'm forced to use > 50 characters, eventually I'll just use "bug fix" to be on the safe > side. I'll much rather have the first line of the commit message > wrapped / truncated in gitk / gitweb than have politically correct, > 50 character first lines that don't describe the commits sufficiently > and make it hard to overview the commits. >
How many times have you looked at old code and cursed the original author because of no/bad comments or a useless commit message? Spending the few extra minutes to edit your commit message in an editor, at the expense of your own convenience, could save hours of time for future devs. Think of the ROI! > > The first line is simply a summary or the topic of the patch. > > ... or the whole commit message. Especially for small commits, > there is no need to do more than one line. A single line commit message, if you can fit it in a resonably sized line, is fine. > > > You can be > > as verbose as you want in the body of the commit message. It's just like > > an email; you wouldn't put the whole body of the message in the subject. > > I personally do not buy the email message analogy (and yes, I know > that's what Linus says ...). > > > Frankly, if you can't summarize a change in 50 or so characters (I > > wouldn't place a hard limit, myself), then your change is probably doing > > more than one thing, and should be broken into smaller changes. > > $ git cat-file commit fdb8c7c881c17ca0c7899e6bfe03e58502586b52 > [...] > Automatic commit of package [spacewalk-setup] release [0.5.27-1]. > > 65 characters. > > $ git cat-file commit 66f35d59c2f4d1771e0b17086a5f85f7c151982f > [...] > 492194 - call waitpid even if reading PROCESS_OUT did not return eof. > > One of the jabberd daemons on Fedora 10 seems not to close its stdout, > so doing just while (<PROCESS_OUT>) blocks forever. Therefor we will > do select'n'sysread, to have a chance to see if the child is ready to > be reaped even if we did not get eof. > > 69 characters. > > $ git cat-file commit 69062132d20311a94893e7f5fef43e7a7166d274 > [...] > 491687 - label the /usr/bin/rhn-sudo-load-ssl-cert wrapper with > httpd_unconfined_script_exec_t. > > 95 characters. > > None of these can reasonably be split into smaller commits. Yes, > I could make the first line shorter, but it would feel cumbersome > trying to fit perfectly complete 70 or 90 character description to > 50 characters, and I'd feel I'd be mostly repeating the same content > in the later lines. I think the first two are fine (like I said, I wouldn't suggest a hard limit). The last could be rewritten as: 491687 - SELinux fixes for rhn-sudo-load-ssl-cert Which IMO even more people could understand when browsing the repo via tig or the like. > > I think that we (myself included) still have lots to improve WRT the > content of the commit messages and that we can address the form > later. > > -- > Jan Pazdziora > Senior Software Engineer, Satellite Engineering, Red Hat > > _______________________________________________ > Spacewalk-devel mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/spacewalk-devel -James
pgptanOpFvzd1.pgp
Description: PGP signature
_______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel
