[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] 0.48 rants

From: CooSoft Support
Subject: Re: [Monotone-devel] 0.48 rants
Date: Wed, 21 Jul 2010 08:31:11 +0100
User-agent: Mozilla-Thunderbird (X11/20100328)

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.


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]