monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Re: more on commit without -b option


From: Derek Scherger
Subject: Re: [Monotone-devel] Re: more on commit without -b option
Date: Sun, 25 Jan 2009 21:21:30 -0700

On Wed, Jan 21, 2009 at 12:52 PM, Derek Scherger <address@hidden> wrote:
When commit opens your editor to write a changelog maybe it should load the buffer with something that looks a *lot* like a committed revision as listed by log. Then, you not only get to see the Ancestor, Author, Date and Branch values of your pending commit but you could also *edit* them before saving the log and actually doing the commit. This essentially changes the format of messages coming back from the commit hook and requires them to have some structure. After getting the message from the hook it would be parsed and the various values would be used for their respective certs.

I've pushed a couple of revs to net.venge.monotone.experiment.changelog-editor that essentially implement this different style of changelog editing. Having used this new changelog editor to commit the two revs involved in its implementation, it seems quite nice to be able to "see" what the revision will look like and to edit the branch you're committing to in the process of writing or finalizing the changelog. The idea that status shows a rev you're working on, commit shows the same thing as you're committing it and log shows the same thing later seems good to me.

There are a few more changes I'd like to make before I'd call this branch finished but I'd like to get some feedback and see what people think first before spending time on them:

(1) We have two different forms of revision summary, one used by commit and status and another used by log. These should probably be unified, I prefer the one that status and commit use slightly. The log output contains "Ancestor:" lines that should probably be "Parent:" to be consistent with other tools and more correct.
(2) The revision_summary function in cmd_ws_commit.cc uses (F("...")).str() += "\n" which looks quite odd and I wonder if there's any real point or if it could use an ostringstream to good effect.
(3) The get_log_message_interactively function in cmd_ws_commit.cc claims "Lines beginning with `MTN:' are removed automatically." but doesn't do anything with them. They are instead handled by the lua edit_comment hook. It seems odd to separate these things but that may be unavoidable in the current arrangement. This new branch removes this stuff altogether.

I can see a few potential problems with this branch or objections to the change in general and I'm curious if they're real or if I'm imagining them:

(1) It's a sufficiently different way of editing a changelog that no other vcs that I know of currently does and may put people off or confuse them the first time they use it. People may just not like it because it's different.
(2) It will break scripts or other tools that currently use the output from status or log or use commit in certain ways. These things are probably supposed to be using the automate interface but they may have no choice if the features they need are lacking. (monotone.el comes to mind as something to be checked; dvc.el as well presumably)
(3) The api changes to the edit_comment hook will break anyone who has a custom hook. Will a simple NEWS entry regarding this suffice?

Comments?

Thanks,
Derek


reply via email to

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