Re: [Monotone-devel] 0.48 rants
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
Re: [Monotone-devel] nvm.options
Timothy Brownawell tbrow...@prjek.net writes:
On 07/20/2010 05:44 AM, Stephen Leake wrote:
Timothy Brownawelltbrow...@prjek.net writes:
On 07/18/2010 08:19 AM, Stephen Leake wrote:
Tim,
Just letting you know I've been keeping up with nvm.options, and it all
looks very good so far.
I think it's ready to merge now. See anything I missed?
The per-command defaults are not there, but that could wait for later.
Otherwise looks good.
There's a CMD_PRESET_OPTIONS that's currently only used once (for
diff). Was there supposed to be something else as well?
Ah. I totally missed that (so much for my thorough review process.
Sigh).
That looks good, and I don't think there are any other options that need
it at the moment.
The options no-unknown/unknown are defined twice - once as
SIMPLE_OPTION(unknown ...)
once as
OPTSET_REL(automate_inventory_opts, no_unknown)
SIMPLE_OPTION(no_unknown ...)
That seems like it could be a problem, but it seems to work.
I went back the the email thread; there is one issue that was brought
up but not resolved:
Change --conflicts-file/--resolve-conflicts-file/--resolve-conflicts to:
--resolve-conflicts resolve conflicts non-interactively
--resolve-conflicts-file arg use the given file instead of _MTN/conflicts
dropping --conflicts-file.
But I think that's best left for another time.
We need a NEWS entry, and something in monotone.texi. How about this:
NEWS
New Features
- Options can now be overridden; you can specify --no-unknown
--unknown on the command line. Similarly, you can specify
--no-unknown in the get_default_command_options hook, then
change it to --unknown on the command line.
monotone.texi, in Command Reference header:
Many command options come in pairs that affect the same value. For example,
@command{mtn log} takes a @var{brief} option; this can be reversed by
@var{no-brief}. This is convenient when building command strings
automatically; @command{mtn log --brief --no-brief} is the same as
@command{mtn log}.
It also helps when setting options in the
@var{get_default_command_options} hook; those options can be
overridden on the command line. For example, if
@var{get_default_command_options} specifies @var{brief} for
@command{log}, you can override that with @command{mtn log
--no-brief}.
The command descriptions describe the most important options for each
command, and only one of each pair of options. For a complete list of
options, see the online help (@command{mtn help cmd}), or the manpage.
We could modify the description of _every_ command that now has a
resettable option. Tedious, but do-able. But perhaps we should consider
generating the command options from the help texts, automatically? This
would be a modification of the 'mtn manpage' command. That way the info
manual would be as complete as the online help.
Or maybe it's ok as is.
I scanned thru the Tutorial; I did not see a good place to use an
overridden option. I don't think we want to specify the
get_default_command_options hook in the tutorial.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Timothy Brownawell tbrow...@prjek.net writes:
On 07/20/2010 05:44 AM, Stephen Leake wrote:
Timothy Brownawelltbrow...@prjek.net writes:
On 07/18/2010 08:19 AM, Stephen Leake wrote:
Tim,
Just letting you know I've been keeping up with nvm.options, and it all
looks very good so far.
I think it's ready to merge now. See anything I missed?
The per-command defaults are not there, but that could wait for later.
Otherwise looks good.
There's a CMD_PRESET_OPTIONS that's currently only used once (for
diff). Was there supposed to be something else as well?
Ah. I totally missed that (so much for my thorough review process.
Sigh).
That looks good, and I don't think there are any other options that need
it at the moment.
The options no-unknown/unknown are defined twice - once as
SIMPLE_OPTION(unknown ...)
once as
OPTSET_REL(automate_inventory_opts, no_unknown)
SIMPLE_OPTION(no_unknown ...)
That seems like it could be a problem, but it seems to work.
I went back the the email thread; there is one issue that was brought
up but not resolved:
Change --conflicts-file/--resolve-conflicts-file/--resolve-conflicts to:
--resolve-conflicts resolve conflicts non-interactively
--resolve-conflicts-file arg use the given file instead of _MTN/conflicts
dropping --conflicts-file.
But I think that's best left for another time.
We need a NEWS entry, and something in monotone.texi. How about this:
NEWS
New Features
- Options can now be overridden; you can specify --no-unknown
--unknown on the command line. Similarly, you can specify
--no-unknown in the get_default_command_options hook, then
change it to --unknown on the command line.
monotone.texi, in Command Reference header:
Many command options come in pairs that affect the same value. For example,
@command{mtn log} takes a @var{brief} option; this can be reversed by
@var{no-brief}. This is convenient when building command strings
automatically; @command{mtn log --brief --no-brief} is the same as
@command{mtn log}.
It also helps when setting options in the
@var{get_default_command_options} hook; those options can be
overridden on the command line. For example, if
@var{get_default_command_options} specifies @var{brief} for
@command{log}, you can override that with @command{mtn log
--no-brief}.
The command descriptions describe the most important options for each
command, and only one of each pair of options. For a complete list of
options, see the online help (@command{mtn help cmd}), or the manpage.
We could modify the description of _every_ command that now has a
resettable option. Tedious, but do-able. But perhaps we should consider
generating the command options from the help texts, automatically? This
would be a modification of the 'mtn manpage' command. That way the info
manual would be as complete as the online help.
Or maybe it's ok as is.
I scanned thru the Tutorial; I did not see a good place to use an
overridden option. I don't think we want to specify the
get_default_command_options hook in the tutorial.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.options
Am 21.07.10 12:18, schrieb Stephen Leake:
We need a NEWS entry, and something in monotone.texi. How about this:
NEWS
New Features
- Options can now be overridden; you can specify --no-unknown
--unknown on the command line. Similarly, you can specify
--no-unknown in the get_default_command_options hook, then
change it to --unknown on the command line.
As I mentioned in my earlier mail the NEWS entry should include more
details what options got hidden, deprecated, replaced and / or removed
exactly. Yes, this is also a tedious task, but given the fact that not
mentioning it might lead to weird user experiences, especially if the
information is also nowhere available else, its a must.
monotone.texi, in Command Reference header:
Many command options come in pairs that affect the same value. For
example,
@command{mtn log} takes a @var{brief} option; this can be reversed by
@var{no-brief}. This is convenient when building command strings
automatically; @command{mtn log --brief --no-brief} is the same as
@command{mtn log}.
It also helps when setting options in the
@var{get_default_command_options} hook; those options can be
overridden on the command line. For example, if
@var{get_default_command_options} specifies @var{brief} for
@command{log}, you can override that with @command{mtn log
--no-brief}.
The command descriptions describe the most important options for each
command, and only one of each pair of options. For a complete list of
options, see the online help (@command{mtn help cmd}), or the manpage.
Since we have quite a few things now which we at least plan to remove in
2.0, I start to think that adding a dedicated manual section for that
purpose is a good idea. What do others think about that?
We could modify the description of _every_ command that now has a
resettable option. Tedious, but do-able. But perhaps we should consider
generating the command options from the help texts, automatically? This
would be a modification of the 'mtn manpage' command. That way the info
manual would be as complete as the online help.
Or maybe it's ok as is.
Actually not quite, e.g. mtn serve currently lists two hidden options,
--stdio and --no-transport-auth, so again I think we have to go over all
these sections and tweak them accordingly, if nobody steps up and finds
a good way to include at least the command calling syntax from the main
program.
I scanned thru the Tutorial; I did not see a good place to use an
overridden option. I don't think we want to specify the
get_default_command_options hook in the tutorial.
We don't have to pack every little feature in the tutorial, this way the
tutorial just gets bigger and bigger. Some things might as well be put
in the advanced uses section.
Thomas.
--
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
Some of these messages are starting to scare me somewhat, especially the ones that suggest that monotone take even more responsibility to start passing options to the editor to jump to appropriate places or include file globbing syntax in the commit template. This is supposed to simply be a changelog editor. Adding the ability to edit other certs seems logical but anything beyond that strikes me as crazy. I've been using monotone for years and I've never been as concerned about monotone development as I am right now, and I haven't seen any indications whatsoever about what the new changelog template may look like. Here's my suggested commit template format. Please comment, if only to shoot everything down. *** REMOVE THIS LINE TO CANCEL THE COMMIT *** --Edit fields beneath this line to modify certificate values-- Branch: uk.co.unchartedbackwaters.simple_cfd.tensor.expr.cse Author: Francis Russell exam...@example.com Date: 21/07/10 13:35:29 --Modifications under line are ignored entirely-- Changes against parent bd846e89bef8324b758f8a2c6e7dde41aa4ddd9d patched include/simple_cfd/cse/cse_optimiser.hpp patched include/simple_cfd/numeric/ginac_expression.hpp Main arguments: - Keeping the changelog message at the top requires no scrolling or anything else and allows instant typing of changelog message in most editors. I really dislike any of these arguments about thinking time. We're supposed to be trying to help to user do things as quickly as possible and I find myself thinking more about how to get to the Changelog: token than the commit itself. - Keeping the changelog at the top permits arbitrary whitespace at the start of the message as it's obvious how it will be interpreted. I guess newlines should be stripped at the end (I'm unsure what 0.47 behaviour was). - The editable section now only includes certificates. Revison and parent aren't certificates and aren't editable and it seems confusing to mix them with editable values. Furthermore, the parent revision is replicated in the entirely discarded section anyway. - The new revision ID is removed entirely because as people have pointed out, there's almost no use for it. - At least to me, parsing is obvious. That is, similar to the svn commit message (and probably other systems), the delimiting tokens actually describe themselves and provide the help text. I found the 0.48 template: - Confusingly mixed editable and non-editable information. - Used delimiters between sections that weren't easily inferable. e.g. Changlog: at the start of a line to begin the commit message, and line of dashes to end it (I think). Francis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
Actually, I'd have: *** REMOVE THIS LINE TO CANCEL THE COMMIT *** read *** MODIFY OR REMOVE THIS LINE TO CANCEL THE COMMIT *** as I assume this would be more consistent with how the parsing works. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
Just for the record, I agree with Francis entirely and second his suggestion. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
On Wed, Jul 21, 2010 at 02:11:37PM +0100, Francis Russell wrote: - Keeping the changelog message at the top requires no scrolling or anything else and allows instant typing of changelog message in most editors. I really dislike any of these arguments about thinking time. We're supposed to be trying to help to user do things as quickly as possible and I find myself thinking more about how to get to the Changelog: token than the commit itself. I've found myself using -m just to avoid the editor entirely. I often like to write a paragraph or two for my commit messages, and I'm writing more and more 20-40 character commit messages lately. I definitely prefer the template Francis included. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
On Wed, Jul 21, 2010 at 10:09 AM, Jack Lloyd ll...@randombit.net wrote: On Wed, Jul 21, 2010 at 02:11:37PM +0100, Francis Russell wrote: - Keeping the changelog message at the top requires no scrolling or anything else and allows instant typing of changelog message in most editors. I really dislike any of these arguments about thinking time. We're supposed to be trying to help to user do things as quickly as possible and I find myself thinking more about how to get to the Changelog: token than the commit itself. I've found myself using -m just to avoid the editor entirely. I often like to write a paragraph or two for my commit messages, and I'm writing more and more 20-40 character commit messages lately. I definitely prefer the template Francis included. I know I'm a brand new Monotone user, and I hate writing me-too emails, but I also greatly prefer the template Francis suggested. It still makes it clear what's editable, but I don't sit there, scratching my head, wondering why my commit aborted due to a blank message when I know damn well I typed a message. (This really was my very first experience with committing in Monotone. It wasn't the best.) This seems like a really nice blend of making it brain-dead easy, but still making it clear what's editable. --Benjamin ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: 0.48 rants
On Wed, 21 Jul 2010 15:32:01 +0200 Ludovic == Ludovic Brenta ludo...@ludovic-brenta.org wrote: Ludovic Just for the record, I agree with Francis entirely and second Ludovic his suggestion. +1 Let me just show how the commit screen looks in darcs... --- cut-here -- foo bar ***END OF DESCRIPTION*** Place the long patch description above the ***END OF DESCRIPTION*** marker. The first line of this file will be the patch name. This patch contains the following changes: M ./devel/haskell-yesod/PKGBUILD -1 +1 --- cut-here -- Clean simple. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 signature.asc Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
Am 21.07.10 19:48, schrieb Benjamin Pollack: On Wed, Jul 21, 2010 at 10:09 AM, Jack Lloyd ll...@randombit.net wrote: On Wed, Jul 21, 2010 at 02:11:37PM +0100, Francis Russell wrote: - Keeping the changelog message at the top requires no scrolling or anything else and allows instant typing of changelog message in most editors. I really dislike any of these arguments about thinking time. We're supposed to be trying to help to user do things as quickly as possible and I find myself thinking more about how to get to the Changelog: token than the commit itself. I've found myself using -m just to avoid the editor entirely. I often like to write a paragraph or two for my commit messages, and I'm writing more and more 20-40 character commit messages lately. I definitely prefer the template Francis included. I know I'm a brand new Monotone user, and I hate writing me-too emails, but I also greatly prefer the template Francis suggested. It still makes it clear what's editable, but I don't sit there, scratching my head, wondering why my commit aborted due to a blank message when I know damn well I typed a message. (This really was my very first experience with committing in Monotone. It wasn't the best.) This seems like a really nice blend of making it brain-dead easy, but still making it clear what's editable. As Derek noted in an earlier mail, we're working on a solution for this and this solution will definitely pop up in the next version (i.e. there will be no next version unless this issue has been resolved, given the huge waves this feature created so far). Just a small hint for all of you which are otherwise scared away from monotone in the meantime - you can still use _MTN/log to jot down your development notes before you hit commit and just save the editor contents afterwards. This way you skip the changelog editing completely, but don't miss the possibility to enter more than one sentence / paragraph in the changelog. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
