You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kristis Makris <mk...@gmx.net> on 2005/05/20 02:24:49 UTC

Re: [ham] Re: RFC: Log Message Templates via new hook.

> would give less than satisfactory results.  Basically, if files were being
> inserted into the template by the hook, the list might not be 100% accurate

Indeed. Also, if the files list is accidentally modified by the user as
to not no longer meet the template, it may throw off some other tool
written to expect that lists template. Perhaps the files list should be
generated by some integration system (e.g. Scmbug) when it's about to be
entered in the bug-tracker comments(e.g. post-commit hook); NOT when the
user is entering the changeset log(log-template hook).

The point here is let's not be tied to keyword expansion in the log
template if possible.

> remove from the list.  Obviously the user can manually fix the message
> which is why it is not a show stopper.

As an example, if a user is in the habit of hitting M-q in emacs every 3
secs to make the editor newline-separate his log comment, the editor
might also rearrange the files list; the user may notice that after
commiting. 

> I guess the other option is that the GUI's could call the hook up-front,
> and not pass it any files.  By convention, hook authors would have to be
> aware of this and perhaps instructed to pass back a variable in the message
> template where files are to be inserted?

I'm not sure why hook authors must necessarily depend on a variable for
a files list, since hook authors could still do so without such a
variable but still following their own convention (e.g. always append a
list of files at the end). If a keyword that represents a files list is
available in the template, the user has the option of accidentally
moving that around.

I'm still catching up on this thread, so I may be missing something. 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org