Derek Scherger wrote:
Starting a series of replies...
On Sat, Jul 17, 2010 at 1:40 AM, CooSoft Support
<supp...@coosoft.plus.com <mailto:supp...@coosoft.plus.com>> wrote:
I'm not currently using 0.48 and from what I hear nor will I. I to
want comments to go in unmolested and not have white space
stripped out. For me that is a must.
I've found that I have commits with random amounts of trailing
whitespace (newlines) and that's the entire reason that for the
trimming. I think Lapo mentioned that he had similar concerns about
how much whitespace would precede or follow his commit message and the
basic idea was to allow people to stop worrying about such things.
Point taken though, perhaps this trimming should be restricted to
leading/trailing newlines and perhaps it should also be configurable
by a hook so that can be controlled.
I personally have no issue with trimming blank lines at the beginning or
at the end of a commit message and like you agree that is better than
not doing it. But non-whitespace lines and blank lines in the middle of
a commit message should be preserved as is (with the exception of blank
lines as they could have any spaces and tabs removed).
Why are date and author changeable? Surely these should be
immutable (apart from one could specify an alternate key on which
to perform the checkin - I assume that the same restriction
applies when changing the author in the changelog (i.e. you have
to have a private key for that user in your keys directory).
They're changeable in the editor exactly because they are changeable
on the command line with --date, --author and --branch arguments and
for no other reason.
Ok sorry - it has never occurred to me anyone would want to do this.
Point taken.
I also agree that the changelog that the user enters should go at
the top. When working with GUIs you quickly learn that trying to
slow a user down and make him/her think about the consequences of
what they are about to do is mostly a waste of time as they simply
get used to clicking on that extra button or in this case
scrolling down x lines...
There was *absolutely* no intent of slowing anyone down with this. It
was about allowing review and changes and unifying the various
randomly different output formats. Configuring your EDITOR with +N
should allow the leading lines to be skipped.
Cheers,
Derek
When I meant slow them down it was in the context of getting them to
review and reflect on what they are doing before doing it. I still think
this will be met with resistance. However, having a simple generic
setting, that when set in the config file, will automatically move the
editor the required number of lines to the entry point should counteract
any resistance. Doing EDITOR=".... +n14" is a bad idea as many other
programs use this. Perhaps do this move 14 lines down stuff by default.
Just a thought.
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel