Sidney San Martín [off-list ref] writes:
quoted
After all, SCM is merely a method to help communication between
developers, and sticking to the common denominator is a proven good way to
make sure everybody involved in the project can use what is recorded in
the repository. This is not limited only to the log message, but equally
applies to filenames (e.g. don't create xt_tcpmss.c and xt_TCPMSS.c in the
same directory if you want your project extractable on case insensitive
filesystems) and even to the sources.
You need to justify the cause a bit better. Why is such a new logic
justified?
You’re right, that sentence doesn't say anything.
I agree that projects need to have standards for their commit messages,
but I also think that line wrapping should be taken care of by the
computer so that the humans can think about the content of their commit
messages. It's easier for everyone.
I just typed M-q to wrap the above paragraph from you to make it readable.
"Computers are good at automating" is true, and that is why real editors
give an easy way to auto-wrap long prose in a paragraph while composing.
But "computers are good at automating" is not a convincing justification
to let the composer leave unreasonably long lines in the commit log object
and force the reader side to line-wrap the mess only to fix it up.
On 13.02.2012 23:25, Junio C Hamano wrote:
"Computers are good at automating" is true, and that is why real editors
give an easy way to auto-wrap long prose in a paragraph while composing.
But "computers are good at automating" is not a convincing justification
to let the composer leave unreasonably long lines in the commit log object
and force the reader side to line-wrap the mess only to fix it up.
Maybe this is more convincing: Only the reader side knows the
line-length of the display or window.
On Feb 13, 2012, at 5:25 PM, Junio C Hamano wrote:
I just typed M-q to wrap the above paragraph from you to make it readable.
Out of curiosity, how do you read your mail? I don’t know anyone whose mail
is set up like that.
I’m happy to wrap my text if it’s tricky for you to read it otherwise — but
FWIW my mail client doesn’t support hard wrapping (I’m doing it in my editor).
"Computers are good at automating" is true, and that is why real editors
give an easy way to auto-wrap long prose in a paragraph while composing.
But "computers are good at automating" is not a convincing justification
to let the composer leave unreasonably long lines in the commit log object
and force the reader side to line-wrap the mess only to fix it up.
I asked in #git how other people handle wrapping. Out of three people who
responded, only one said that they had configured their editor (the other two
do it by hand). One thought that Git already did dumb (character-level) line
wrapping, but it turns out he had set LESS= and GIT_PAGER='less -FRX'.
So, even if it is possible to set up your editor to wrap prose appropriately,
I don’t think it’s as common as one might hope.
I’m not suggesting that the reader side should take care of the wrapping
because it *can*, I’m suggesting that it shouldn’t take specially-configured
editors to get consistent and good results — which I assume is why virtually
all new prose-writing tools do wrapping on the viewing end.
What do you think about Git UIs which use proportional fonts for text where
hard wrapping doesn’t work at all? (I brought this up before but want your
take on it).
And, using man and, now, "git help -a" as examples: they both adapt their
output to the width of the user’s terminal. Isn’t that a good thing?
If those aren’t good justification… what would be?