Re: [Monotone-devel] 0.48 rants

[CooSoft Support]

Derek Scherger wrote:
> Starting a series of replies...
>
> On Sat, Jul 17, 2010 at 1:40 AM, CooSoft Support 
> <address@hidden <mailto:address@hidden>> 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.