On Mon, Apr 12, 2010 at 4:06 PM, Thomas Keller wrote:
> No, I just tried it out and it already looks much nicer, though I still
> miss the "end" of the editable changelog area somewhat - maybe this is
> just me who looks for some visual separator.
>
One minor peeve I have with the current editor (on mainline) is that you
don't really want to put a blank line after the message or it will be
displayed as 2 blank lines after the revision is committed. If I reformat
the paragraph I'm typing in emacs with fill-paragraph and there is no blank
line following my message it pulls in all the MTN: prefixed lines and makes
a bit of a mess. With the new format I was sort of relying on the fact that
there would be a blank line following the message to prevent fill-paragraph
from being overly greedy. Maybe this delimiter is too subtle though?
Presumably someone could write a monotone-commit-mode for emacs and
something similar for vim that would allow the editor to prevent you from
editing things you're not supposed to.
> I have to admit I used the comment command the first time today. I now
> know what you mean, mtn comment REV fires up an editor with the
> possibility to add multi-line text. While you can add linebreaks in
> other certs as well, its usually a bit harder to do so and people don't
> trap into that. I initially thought that a comment cert's value could
> simply appended to the header section in mtn log or similar, but it
> makes more sense to deal with it just like with normal changelog certs.
>
See 'mtn log -r 0f1782f7e2348f991a0b8eeac03c45a72c8633a2' for a revision
with a few comment certs. I think the current format does a reasonable job
there.
###
> Enter a description of this change following the ChangeLog line.
> The values of Author, Date and Branch may be modified as required.
> Any other modifications will will cause the commit to fail.
> *** REMOVE THIS LINE TO CANCEL THE COMMIT ***
> --
> Author: m...@thomaskeller.biz
> Date: 12.04.2010 23:44:27
> Branch: biz.thomaskeller.test3
>
> ChangeLog:
>
>
> --
> Parent: ace2791b0b3df530b449802ce82fd8d731a466f1
>
> patched foo
>
>
>
> What has changed? Parent has been moved down into the ChangeSet section.
>
I had considered this a while ago but then forgot about the idea so thanks
for reminding me. We currently have the Parent listed twice, once in the
header and a second time before the changeset. Maybe we should drop the one
in the header and only include it with the changeset, DRY and all that.
I wouldn't call it ChangeSet but Parent, simply because it is the parent
>
Interestingly (maybe) in the code what is being displayed is exactly the
changeset from the revision which is where the name came from.
> we denote with the revision. Revision is gone from the commit header as
> well - is there any use case displaying this for uncommitted revisions?
>
None that I can think of... I was looking for consistency but I'm fine with
dropping the Revision line from commit and status. Any objection to dropping
(or moving) the Parent lines down with their changeset details?
I would probably not change too much in mtn log, i.e. separators for
marking an editable section are not needed here. I'd also keep most of
> the structure as it is now - also because I think we still have a couple
> of users which read in mtn log and parse it somehow directly because of
> the missing automate functionality for that. I know that this is a bit
> against your aim to provide a single way of displaying cert information,
> but maybe its worth to not do it exactly the same...?
>
I was hoping/expecting to hear from anyone who might be parsing the log
output if they were concerned with the changes being proposed. By unifying
the formats I was hoping that people could see what their revision would
look like before they've committed it so that there aren't any surprises
introduced by the different formats. The mess of functions to display certs
in log is mostly gone on this branch and that's one part of the change that
I'd like to keep. ;)
Hrm, no, probably not that far. Ok, forget the RFC :) If you think its
> easy enough to add some basic custom cert adding, then do it, otherwise
> we wait for a feature request...
>
I'm punting for now. We can add this later if it becomes important.
> > I'll have a look at this and see where the extra newline is coming from.
> >
> >
> >> #
> >> mtn: warning: This revision will create a new branch
> >> Old Branch: biz.thomaskeller.test
> >> New Branch: biz.thomaskeller.test3
> >>
> >> --
>
Status explicitly outputs a blank line after the old/new branch details
which can be changed if we want. I like the idea of adding this information
to the instructions for commit if/when the branch is changi
