New Message Extension

[Adrian Buehlmann]

On 03.09.2009 15:41, Yann E. MORIN wrote:
> Adrian,
> All,
> 
> On Thursday 03 September 2009 15:22:35 Adrian Buehlmann wrote:
>> cd libxy
> [--SNIP--]
>> Nope. message.txt is not here!
> 
> OK.
> 
>> hg mes -e  (finish the comments)

insert here:
*hack* *hack* (and forget doing it)

>> hg ci
> 
> Which is then redundant, since hg ci will open the editor, right?

see above

>> * you don't have to remember the file name ('message.txt') or location
> 
> OK.
> 
>> * tools can access it, due to standard location
> 
> What tools?

TortoiseHg, for example. I intend to present '.hg/message' in
'hgtk ci' and write it from that dialog.

Another point is: Do you add 'message.txt' to .hgignore?
(speaking of your alternative workflow...).

>> * hg ci will present you the message, preloaded into the editor
>>   (with the usual HG: lines at the bottom). hg ci --logfile in
>>   contrast just commits without starting the editor
> 
> OK.
> 
> So how does it play with, say, mq?

Not intended to be used with that, since you have qrefresh -e
there.

But I'm open to any ideas here.

The new extension seems not to harm mq (e.g. 'hg ci' still warns
if there are applied patchs -- "abort: cannot commit over an applied
mq patch")

> Not saying that's not useful, but just trying to spot some corner-cases,
> to see how they can be resolved if need be.

Sure, thanks for the feedback.

Issues and feature requests can also be entered at
http://bitbucket.org/abuehl/hgext-message/issues/

> Now, I can see where it can be useful. I usually use mq, even for a
> single change, so I can indeed pre-fill the commit message, and update
> it prior to making the change a definitive changeset. Using this
> extension would nicely replace mq in this context.

Exactly. That's what I often do too (use mq to prefill the
commit message).

mq is a problem for newbies though. It took quite some time until
I felt comfortable using it myself.