monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Monotone Commit Template


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Monotone Commit Template
Date: Sun, 23 Sep 2007 09:32:16 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

On Sun, Sep 23, 2007 at 02:12:33PM +0200, Ralf S. Engelschall wrote:
> Searching the parent dirs might be not the best idea.

Agreed.

> For the remaining functionality the following does the trick for me:
> 
> Index: std_hooks.lua
> --- std_hooks.lua     6ca29b67a6913342668b4cfa2464a37654615280
> +++ std_hooks.lua     3852a7038c60e2389b3d1438906439794999d443
> @@ -271,6 +271,13 @@ function edit_comment(basetext, user_log
>     if user_log_message == "" or string.sub(user_log_message, -1) ~= "\n" then
>        tmp:write("\n")
>     end
> +   local template_log_message = read_contents_of_file(".mtn-message", "r")
> +   if template_log_message ~= nil then
> +      tmp:write(template_log_message)
> +      if template_log_message == "" or string.sub(template_log_message, -1) 
> ~= "\n" then
> +         tmp:write("\n")
> +      end
> +   end
>     tmp:write(basetext)
>     io.close(tmp)
> 
> Should we commit such a change or do we need a more sophisticated solution?

This is broken, unfortunately -- e.g., if the user starts a commit,
aborts it, then tries again, they will end up with multiple copies of
the template in their log message.

I think the right way would be to modify the "after a successful
commit or checkout, blank out _MTN/log" logic so it becomes "after a
successful commit or checkout, either write the contents of
.mtn-message to _MTN/log or else if that file does not exist then
blank out _MTN/log".  (Update is an interesting case here, since
.mtn-message could change, but the user might have already written
some stuff to _MTN/log.  Maybe we should just add a check to see
whether .mtn-message has changed during and update and print a warning
to the user if it has, so they're at least aware.)

What charset should .mtn-message be interpreted to be in, current user
preferred charset or always-utf8?  Always-utf8 seems more viable,
though I'm sure it will bite someone at some point.

-- Nathaniel

-- 
In mathematics, it's not enough to read the words
you have to hear the music




reply via email to

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