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.
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).
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...
Francis Russell wrote:
I was intending to write about the new commit template stuff too. Having
the commit message in the new location has significantly increased the
effort and time which it take me to make a new commit. I considered
downgrading back to 0.47 just to avoid it. I really feel that I
shouldn't have to memorise the fact that the 'Changelog:' token is on
the twelfth line. In addition, the new white-space handling is a pain. I
sometimes like to use commit messages of the form
- item1
- item2
but the parser swallows any initial whitespace so I can't indent the
first line.
I also feel the template bombards me with information that I already
know or don't really care about when all I want to do is type a commit
message. I don't need to read a help message on how to edit the
changelog and other fields every time I commit and I can't imagine what
anyone might learn from the parent revision or current revision hashes
that they didn't know before they decided to commit.
I'm all for displaying the author, date and branch in the footer as
these are user-editable modifiable values that they could conceivably be
wrong. In particular, I've often committed to the wrong branch without
realising it but I feel adding a second mechanism to edit these just
duplicates functionality and adds the complexity of a parser. I suspect
most monotone users are reasonably sophisticated people who don't need a
meta-interface to edit values they could already have specified on the
command line though others may disagree.
Francis
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
