[PATCH 1 of 2] commit: save commit message so it's not destroyed by rollback
Matt Mackall
mpm at selenic.com
Mon Nov 23 13:02:37 CST 2009
On Mon, 2009-11-23 at 19:43 +0100, Adrian Buehlmann wrote:
>
> On 23.11.2009 18:56, Matt Mackall wrote:
> > On Mon, 2009-11-23 at 13:17 +0100, Adrian Buehlmann wrote:
> >> On 23.11.2009 13:02, Martin Geisler wrote:
> >>> Adrian Buehlmann <adrian at cadifra.com> writes:
> >>>
> >>>> On 23.11.2009 10:11, Martin Geisler wrote:
> >>>>>> It's probably best if Matt just picks a name and ends this discussion.
> >>>>> I don't think we should not channel every little decision through
> >>>>> Matt, I'm sure he has better things to do :-)
> >>>> I'm not entirely sure that Matt would prefer having a .txt suffix,
> >>>> since it would be clearly a deviation from current naming standards
> >>>> inside .hg.
> >>>>
> >>>> It's surprising though to read that you see the current naming
> >>>> of the other files inside .hg as broken.
> >>> Well, broken is too strong... all I wanted to say is that it would not
> >>> have hurt anybody if we had added '.ini' or '.txt' from the beginning.
> >>>
> >>> The question is whether we should continue this style for new files too.
> >>> I can definitely see that it's nice to keep things consistent, but it's
> >>> also nice to make things ever so slightly easier.
> >>>
> >>> But perhaps it doesn't matter here -- if people use .hg/message as
> >>>
> >>> hg commit -l .hg/message
> >>>
> >> ...or even simpler just use
> >>
> >> hg ci
> >>
> >> and have the message extension [1] enabled in their ~/.hgrc, which
> >> will automatically preload .hg/message into their editor.
> >>
> >> [1] http://mercurial.selenic.com/wiki/MessageExtension
> >
> > This extension convinces me that 'message' -is- the wrong name. Because
> > now this pre-existing extension will always be loading your -last-
> > commit message on your next commit!
>
> That's what the extension already does today.
>
> It preloads your last commit message on the next commit. Unless you
> change the message with 'hg message -e' or -C before committing.
Why would anyone ever want that, aside from the exceptional case of
redoing the last commit?
I can see wanting either of the following, possibly in combination:
- an -empty- template to fill on each commit
- a pre-written commit message, edited over the course of work (and then
cleared back to a template on commit - missing in your extension)
But always starting with your last commit message? That seems entirely
unhelpful.
And reading message.py, it's also not what your extension is doing until
Greg's patch is added. Your extension only writes to message when the
'message' command is used, not on commit. And it never looks at the
changelog.
As far as I can tell, using 'message' to store the current commit
message destroys any usefulness of your extension.
--
http://selenic.com : development and support for Mercurial and Linux
More information about the Mercurial-devel
mailing list