(Unless some new argument appears, this will be my last response in
this thread.)
Olleg Samoylov <olleg@mipt.ru> writes:
> I undestand why this happens. But your can't undestand one simple thing.
> One line message is always one line message. And every human can
> approve it. No matter how computer make wrong decision.
I don't understand this (but I don't think it's a language problem).
> > If you truly want one line, why not just remove everything but that
> > one line?
>
> As I already said, if a bug have a workaround it don't begin looked
> like a customizable feature.
>
> > I don't think the patch is an improvement, because it's not clear that
> > the current behavior is incorrect. Defaulting to having the newline
> > seems reasonable, at least as reasonable as not having it.
>
> Well, let me explain again. "svn log" don't expect EOL at the
> end. "svn commit --message", "svn commit --file" and "svn commit"
> (with editor) don't add EOL if it not exist. Almost code wroted as if
> log message have not trailing EOL.
This is irrelevant. Those modes take their log message data in final
form. The mode we are discussing takes the data in non-final form and
has to tweak it before committing. We are discussing the right way to
tweak it. If any other command also had to tweak it, then this
discussion would apply to that command too.
I don't understand why you characterize it as "adding" an eol. If the
log message looked like this:
Here is my multi-line log message.
This is the second line of my log message.
This is the third line of my log message.
This is the fourth line of my log message.
This is the fifth line of my log message.
--This line, and those below, will be ignored--
...would you expect the last line to keep its trailing newline? If
not, why not? Or if so, then why would the reasoning change when the
log message is one line instead of five?
> There is chose. Rewrite almost code to support log message with
> trailing EOL, as Greg like. Or fix bug. Or do nothing? What your
> prefer?
Do nothing. I think the current behavior is fine, and not a bug.
> IMHO, will be convenient remove all white spaces at the end, not only
> EOL. They arised by mistype usually. Don't have any useful
> information. And invisible for human to fix it manualy.
>
> Do you have argument to negate this?
Here is the same argument I made before, but expressed more clearly.
Assume that the log message in the editor says this:
here is my log message
--This line, and those below, will be ignored--
And now the user saves, exits, and thus finishes the commit, without
editing the log message any further. In this circumstance, some users
will want the newline after "message" preserved, and other users will
want it stripped. Subversion has no way to guess which way a
particular user wants. For example, I always want it preserved,
whereas you apparently always want it stripped.
Each of us can guarantee our desired outcome, by simply removing the
newline and the separator line, and anything below that. So the only
question is, what should Subversion do by default, if we *don't*
remove those things? I agree with Greg that most log messages are
meant to be treated as a series of lines, and that therefore a
reasonable default is to put a newline after the last line (yes, even
when the last line is also the first line). This is not enforcing
anything; it is *choosing* a good default when the user has expressed
no clear preference.
I don't really understand why you think this behavior is a bug, but as
you've tried to explain it several times now, I think I am unlikely to
ever understand.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 22 18:21:25 2005